(no title)
jprotopopov | 5 months ago
I am in no way accusing any of libc developers, they got much higher priority things to do than supporting obscure compilers, and this is my problem as a compiler developer, but nevertheless. For instance, glibc may simply override __attribute__ keyword with an empty macro, or omit packed attributes for non GNU C compilers (breaking epoll ABI along the way). Of course, strictly standard-compliant compiler may not have attributes at all, but in my opinion #warning/#error directive would have been more appropriate than silently producing ABI breakage.
Although, I have not engaged with glibc developers on these topics, and mostly documented encountered challenges as patches in my own test suite.
1718627440|5 months ago
jprotopopov|5 months ago
Here I am not speaking about the compiler optimizing based on known libc behavior, but libc "specializing" based on assumed compiler behavior. Which is, again, absolutely reasonable -- both compiler and libc typically go hand in hand. However, as my compiler "parasites" on the existing libc implementations, I would have preferred that such assumptions would be validated to the extent it is possible at compile time, preferably with some graceful failure.
Glibc provides quite profound libc part even to non-GNU C-compatible compilers, but in some places it might fail silently and disruptively.
I am deeply thankful to all developers of libc implementations for Linux and BSD systems, and I am in no way accusing anyone or demanding anything. In the project's README I explicitly note, that any standard library function not being usable will be treated as a bug in Kefir itself. In the above rant, I just expressed a mere wish that some things could be a bit smoother.