I heard from somewhere that technically, OS X does not preserve backward compatibility for system calls, so you should use libc function's instead, otherwise it is an undefined behavior. Whereas Linux keeps a hard compatibility guarantee. Is that true? I guess Apple will really hesitate before commiting breaking changes, but I'm genuinely curious if they reserve the rights in thoery.
This is true - the compatibility boundary for OS X is at the link-against-libSystem layer. The actual interface between libSystem and the kernel is private to Apple and is not guaranteed to stay argument or ABI compatible. (this includes the syscall() function)
Several xnu syscalls are actually paired with a userspace wrapper function that does some extra stuff. Existing syscalls may even become wrapped in a subsequent release if needed.
I don't know about OS X. You're right about Linux, though, and Torvalds will descend into an angry screed if you try to break the ABI. Windows, on the other hand, does not save the numbers between releases. http://j00ru.vexillium.org/ntapi_64/ is a table showing the system call table for each given release, and how sometimes it even changes between service packs of the same released OS.
> I heard from somewhere that technically, OS X does not preserve backward compatibility for system calls, so you should use libc function's instead, otherwise it is an undefined behavior.
I believe this article[1] definitively answers this as being the case.
> Whereas Linux keeps a hard compatibility guarantee.
Not being a troll here... Why would anyone care unless they are writing a libc replacement? Before anyone objects regarding compatibility with programs written for older versions of OS-X, there have been compatibility libraries distributed for every version I can recall. To wit, I run the Pages app from iWork '09 regularly.
> Why would anyone care unless they are writing a libc replacement?
- So that you can feel safe upgrading your kernel without upgrading your whole userspace. (Linus harps on this one a lot.)
- So that there can be multiple competing libc's. Linux is used in a lot of diverse environments, and the tradeoffs made by glibc (in terms of bloat, license, etc.) are not necessarily the best for everyone. Android does not use glibc, for example.
- So that you can isolate apps from each other using containers (hermetic chroot environments), where different containers may have entirely different libc. Docker (and my own Sandstorm.io) relies very heavily on Linux's syscall ABI compatibility promises.
- Because the syscall ABI is frankly a much clearer boundary than the libc ABI, and arguably easier to keep backwards-compatible. An app literally _can't_ break this boundary and access the private interfaces beneath (assuming a secure implementation, lol).
Gotcha. I guess it's an OS expectation thing then. In OS-X, it's pretty much an assumption that dynamic linking is what's going to happen (good or bad).
Linux userland has various libcs available (klibc, glibc, eglibc, uclibc, dietlibc, musl, …), with distributions occasionally switching between them, and ABI-incompatible changes happen every once in a while. Source-distributed software does not have to care usually, but for binary-only distribution, statically compiling the libc is the easiest bet. Thus, the kernel has to maintain compatibility.
More than that, static linking is very difficult indeed as there is not even a crt for static linking let alone libc.a, you would have to write your own.
> Not being a troll here... Why would anyone care unless they are writing a libc replacement?
Linux doesn't have any single fixed libc, the system call interface is the public API. Indeed there are many different libc's used in different linux applications - glibc on many desktop distros, bionic libc on android, uclibc, musl and others on various embedded/specialized setups.
