3 ms·
> 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 AB
by 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?