Re:C library system-call wrappers, or the lack thereof
by tacostakohashi on Tuesday November 13, 2018 @10:38PM
(#18447272)
One issue with that idea is that the source code for implementing a system call is necessarily compiler-specific, it is not standard C. So, the issue would become which compiler (version) should the source code of the include/ and src/ be for? GCC? Clang?
[ Parent
| on HN ]
Re:C library system-call wrappers, or the lack thereof
by olliej on Tuesday November 13, 2018 @11:38PM
(#18447533)
A lot of the problems occur in things like struct layout of syscall arguments, which would be cross platform.
But then you run into the problem of how willing to commit to ABI stability in a non-posix API. I assume there’s some commitment to such at the moment, but how much also depends on *libc abstracting them? Libcs always seem to (to me) be approximately kernel version specific
Re:C library system-call wrappers, or the lack thereof
by Aic1kuir on Wednesday November 14, 2018 @06:38AM
(#18449130)
Ancient glibc versions run ok on current kernels, you're just missing out on some newer features. Otherwise statically linked binaries would cease to work.
Re:C library system-call wrappers, or the lack thereof
by zaarn on Wednesday November 14, 2018 @07:43AM
(#18449403)
There is still a limit, very old software doesn't run anymore, largely because something in the kernel broke it. But it has been years and nobody complained so nobody will revert this or fix it.
Linus has stated as such and I think a few other maintainers agree there. If you don't find the problem until years later, chances are, too few people care.