4 ms·
An operating system has an ABI. Programs compiled from C source use the OS's ABI. There is no "C ABI". The very premise of TFA is fundamentally incorrect, and
by bregma 5y ago
An operating system has an ABI. Programs compiled from C source use the OS's ABI. There is no "C ABI".
The very premise of TFA is fundamentally incorrect, and there is no way to reach a valid conclusion from an incorrect premise.
- falcor84 5y agoI think your argument kinda agrees with TFA, as it's stating that C's nature as the defacto ABI for all interoperability on all operating systems is in conflict with it trying to, at the same time, still be a programming language. It would be very nice to have a non-C ABI.
- bregma 5y ago> C's nature as the defacto ABI... It would be very nice to have a non-C ABI. > An operating system has an ABI. Programs compiled from C source use the OS's ABI. There is no "C ABI". I'm having difficulty getting these two ideas to reconcile.
- deleted 5y ago[deleted]
- riking 5y agoOn many platforms, such as FreeBSD and macOS, the application-exposed ABI for tasks such as "open a file" or "validate this x.509 TLS certificate" mandates that you link to a shared library and call into it using the C calling convention. (libc and Security.framework, respectively.) Linux is unique in that you can hand-write assembly to perform a system call and have it work across OS upgrades. FreeBSD does not have stable syscall numbers: open() must be a libc call.
- thatsnotc 5y agoThe application-exposed ABI for those tasks mandates that you execute a few assembly instructions to make a syscall (and perhaps also do some work that the libc normally wraps around the actual syscall for you). ABIs deal with machine instructions, that's why the "binary" is in there. The OS-provided API for the tasks are libc and Security.framework. Do you have any suggestions for a better API?