> On Jul 5, 2017, at 05:31, Jan Stary <[email protected]> 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 >
Depends on where it appears. If it's added to a .o file, I'd be worried; but if it only appears when creating a full executable, then it's just another flavor of added runtime support, perhaps to bridge the difference between what the compilation environment is attempting to support in terms of source, and what the system offers in terms of needed system calls or library functions. And in the case of providing a builtin inline implementation of a well-known function if nothing is taking its address (so there's no worry of possible later use via a pointer-to-function), then even a .o file might have something added to it whose provenance may not be entirely obvious.
signature.asc
Description: Message signed with OpenPGP
