Is it time for a libc_fixes library yet?

[Jan Stary]

On Jul 05 08:28:40, ken.cunningham.webuse at gmail.com wrote:
> 
> 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/>. 

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