On Jul 05 08:28:40, [email protected] wrote: > > On 2017-07-05, at 2:31 AM, Jan Stary wrote: > > > On Jul 04 13:47:27, [email protected] wrote: > >>>> > >>>> Perfect would be if I just wrote it into the clang code directly. > >>>> I am almost to the point where I could do that, actually. I know where > >>>> it would go, I think. > >>> > >>> I don't get it. Do you mean to mess with the compiler so that > >>> it implements itself the C functions that the system does not provide? > >> > >> > >> Yep :> That is just exactly what I mean.... clang does stuff like this > >> already to help you out. Adding in various libraries, rearranging header > >> paths, sticking in compiler and linker flags, all to suit to build system > >> and make things work. > > > > Does clang currently provide implementations of functions that do not exist, > > and link against them if the code calls them? Would you please shre an > > example? > > > > If so, it seems to be quite a deviation from what a compiler is supposed to > > do. > > If I call a compiler, I expect it to compile the given code, not something > > that > > > > 1. the system does not provide > > 2. the standard library such as libc does not provide > > 3. the given code does not contain > > > > Jan > > > > > So, just spitballing here as it appears this idea is not too popular already, > but to answer your question. > > IClang does in fact provide some of it's own replacement functions that are > either highly optimized, or don't exist on some targets (like the blocks > runtime implementation provided to linux). > These features of clang are in > the compiler runtime library <https://compiler-rt.llvm.org/>.
The features described there seem to be quite different then e.g. implementing a missing strnlen(), which is what your lib does. The compiler runtime is described as "optional" at http://clang.llvm.org/get_started.html so I assume a default build of clang does not use it. Do the clangs provided by the MP ports use it by default? > It appears fairly easy to extend this, but that would not likely be the way > I'd choose to do it with my skill level. Instead of that, Clang quite easily > can call in support libraries (ffi, omp, all those other ones you see listed > as deps). Do any of those reimplement or otherwise substitute standard libc functions such as strnlen() or getline()? > Very easy would be to have clang list snowleopardfixes (or whatever it might > be called to make everyone happy, but I guess that name is sticking for the > moment and probably forever now) Traditionally, I believe, things like this are called "libcompat". > as a library dependency either on macports or as a subproject of clang itself, Didi you talk to the clang upstream about this? Do they already have a thing like that for some other systems? I just don't see something as general as compiler suite having a "snowleopard fixes" subproject. > and then in the clang compile line handling code do something like this: > check the deployment target > if < 11 { > add in the snowleopardfixes include directory ahead of the system include path > add in a link to -lsnowleopardfixes > } Perhaps it is a point of view, but I don't think it's the compiler's job to implement a getline(3) itself. > Then a call to #include string.h would find the snowleopardfixes version of a > string.h first, that would call the official system one and then add in the > extra couple of definitions for getline, etc. And there would be another one > for memmem and I guess a third for the ws* stuff. Please don't. It is the source's job to have a compat_getline() if it is to be ported to systems that don't have getline(), or the porter's job to provide that as a patch. This is a UNIX system. Tweaking the compiler and doing clever hacks around standard string.h seems like the opposite of "keep it simple". Jan
