Hacker News Reader

Comment by bregma | Hacker News Reader

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.

View on HN

I 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.

> 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.

On 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.

The 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?

Reply on news.ycombinator.com