Comment by _g6sn | Hacker News Reader

Comment by _g6sn | Hacker News Reader

Parent Full thread

I am going to hijack this comment for a little rant about libc and independent compilers. Existing libc implementations have varying levels of hostility towards non-gcc/clang compilers. Glibc is probably the worst offender here, musl is the most compliant (but even there are some assumptions).

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.

The libc is part of the C implementation, i.e. part of the compiler. It's not a bunch of helpful utils like in other languages. The compiler is allowed to optimize based on ever behaviour it knows its libc has. It's nice that you sometimes can swap out the libc, but its a hack.

Yes, indeed, libc behavior (at minimum) is defined by the standard itself, and the compiler has to ensure that the library is functional. I have explicitly acknowledged it in my comment above ("this is my problem as a compiler developer").

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.

Fair enough.

Thanks for your work, more diversity will always improve the C language and your work is truly impressive.

>

Nice clean HTML5 website there, I wish more would be like this. There are however some errors in the <a> tags (lines 120-133), you seem to generate? an open instead of a close tag there.

Thank you. On that subdomain, nothing was generated -- I just sat down and typed it in the editor for no particular reason. Should have validated it, at least

Edit: The external source archive page was. Although, with a very simple bash script, but nevertheless

Reply on news.ycombinator.com