Is it time for a libc_fixes library yet?

[Ken Cunningham]

On 2017-07-05, at 2:31 AM, Jan Stary wrote:

> On Jul 04 13:47:27, ken.cunningham.webuse at gmail.com 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/>. 

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).

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) as a library dependency either on macports or as a subproject of clang itself, 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
}

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.

Probably could do this without much trouble at all, I think. It would be better, really - provide proper headers and function definitions, fix older systems, no effect on newer ones.

[Most likely could even supply the blocks runtime to 10.4 and 10.5 while we're at it :> , to get ld64-137+ running on PPC -- but I digress.]

But I'm not actually suggesting heading down this road at the moment. Lets see if the snowleopardfixes library makes things better by itself.

Ken