zlacker

Except notably Linux where the kernel ABI is the thing that’s stable.

>>vlovic+(OP)
glibc actually goes through quite a bit of effort to remain backwards compatible. There have been times when mistakes were made here, but the extent to which glibc does not have a stable ABI is overstated. The only annoying thing about glibc and ABI stability is that the way it achieves that is via symbol versioning which makes it annoying to target an old glibc on a system with a new er glibc.

>>mikepa+s2
I didn’t mean to imply that glibc’s API isn’t stable. Just that the stable API boundary for the kernel on Linux is the syscall ABI, not libc.

>>vlovic+i3
Ah sorry, I misunderstood

>>vlovic+i3
Another stable ABI boundary is anything produced by glibc that can be conceivably placed into memory shared by different unrelated processes (ie. Posix IPC primitives). The requirement for backwards compatibility and architecture variant compatibility (32b/64b…) is the largest reason why things like pthread_mutex have somewhat large overhead and why it is worthwhile to invent various iterations of “futex in userspace”.

>>mikepa+F5
No worries. My wording was muddled.