Hacker News Reader

Comment by dleslie | Hacker News Reader

This is a strange complaint that seems to reduce to C not having a well defined ABI.

Of course it doesn't. C implementations do. This isn't really any different than most other languages, but feels different because C doesn't have a blessed implementation that all other implementations must interact with.

That's a strength. It means C is found on esoteric microcontrollers as well as powerful modern desktops. That wouldn't work as well as it could if the ABI were uniform on all targets and implementations.

And yes, it can act as a protocol. It's the simplest way to access host ABI communication without understanding it.

View on HN

Many of these implementations are needlessly weird and underspecified. C happens to work despite these quirks due to sheer amount of hours everyone puts to work around C's critical but vague notion of an ABI.

The fact that the biggest compilers don't quite agree on the ABI for the most popular desktop CPU is not a success of C's portability or flexibility, just a historical quirk caused by the C language moving slower than evolution of the hardware and needs of operating systems.

It's not a quirk of C; it's a failure of the vendors and their partners to appropriately coordinate. This outcome happened _despite_ the best efforts of toolchain developers to provide harmony.

The C standard working group is the avenue for vendors/partners to coordinate. Whenever the standard settles on "implementation defined" that's a confirmation that the vendors failed to reach an agreement (often because the standardization effort happened too late, and they've already implemented diverging solutions, and nobody wants to break their userbase).

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.

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?

The complaint seems to be less that C as a whole has a lot of ABI implementations, and more that those individual implementations themselves are also not very well-defined, even on the biggest platforms.

That is, in principle the strength of supporting a wide variety of platforms has absolutely nothing whatsoever to do with the quality of implementation on those platforms.

Linux and Windows have had rock solid ABIs for decades now. Just about any system-appropriate 32bit binary will run on either, if the necessary system libraries are present.

Again, this really doesn't seem related to the article. Nobody is saying those ABIs are making breaking changes, but that they are poorly documented and full of edge cases that make it difficult to reliably produce one of those system-appropriate binaries, short of just giving up and pulling in the platform's entire C toolchain.

Outside of only the most trivial microcontrollers you're going to find edge cases numbering proportional to the complexity of the system. Software complexity is hard.

I'm not sure what's the goal in complaining about that. Just venting?

Just because it's hard doesn't mean it's already been done in the best possible way. Finding and documenting flaws (or "venting") is a great step towards improving.

Seriously though what on earth is your point here? This is an incredibly thorough article on an interesting, difficult subject, with a lot of room for different technical choices. Do you just not like the tone?

The author failed to prove that the current way isn't sufficiently good, or even that C is particularly bad in its role. They've only maligned its use and failed to appropriately consider why it's used.

> Linux and Windows have had rock solid ABIs for decades now

Except they don't. The OS doesn't have an ABI at all, the specific complier does. That's why there's unique triplets for windows for whether or not you're compiling for msvc or gnu, as in x86_64-pc-windows-gnu vs. x86_64-pc-windows-msvc. Both are x86_64 windows, yet they are different ABI targets.

And even on MSVC windows alone there's not even a single ABI - there's __stdcall and __fastcall which change the ABI on a per function basis, and compiler options that change the default convention ( https://docs.microsoft.com/en-us/cpp/build/reference/gd-gr-g... ). So to figure out how to invoke Windows' "rock solid" ABI you need to not only know the header & compiler used, but also the compiler parameters.

Similarly, again per the article, clang & gcc on x64 Ubuntu 20.04 can't actually call each other reliably. They don't agree on a few things, like __int128 which is actually documented explicitly by the AMD64 SysV ABI!

Esoteric microcontrollers don't need an ABI. ABIs are for static and dynamic linking, and in the microcontroller world, there isn't a whole lot of linking going on. It's very common to statically compile everything into one single flash image, with libraries being in source form. E.g. this is the case in the Arduino ecosystem.

They still have an internal ABI used when static linking; aligning structures, laying out data sections, function call behavior, and so forth. C's flexibility/ambivalence in this regard is why it's preferred on those architectures.

One could consider static linking in this scenario just an optimization for incremental builds with separate compilation of source files; it's not really used to, e.g. link a library that has no source. In that sense, it's just an implementation detail that's leaked from a build system that notionally recompiles from source but has unwisely exposed the units of its caching system.

Microcontroller programs are also pretty small; it's not difficult to load the whole program into memory on a workstation and compile the whole thing together. This is how Virgil (circa 2006) worked.

You still have to make choices that may conflict with languages that strictly define their internal binary representations.

And I definitely have received .o files from vendors.

I don’t think there is anything wrong with the single compilation unit approach, but every embedded project I’ve been on on the last 10 years has used static linking, which doesn’t preclude ending up with a single flash image. 10 years is about the last time I worked on a non-arm based project, so that could be a factor (the pic compiler I was familiar with at that time did not have a linker, and I’m not sure if the avr compiler I used did)

> This is a strange complaint that seems to reduce to C not having a well defined ABI.

The complaint isn't that C lacks a well defined ABI, it's that e.g. x86_64-unknown-linux-gnu potentially lacks a stable ABI.

x86_64 linux has long had a stable ABI. Any given target for C is as stable as the host developer wishes it to be.

This is less about stability and more about clarity. The most unchanging and unbroken ABI in the world can still be a huge mess of undocumented special cases only really accessible via the combination of the platform's C compiler and its headers.

This. The intention for C was never to have an immutable, well defined super-portable ABI so that all the people who like to feel superior for not using C can paper over their C use in comfort. It just so happened that C is so simple that it is some 80% along the way to an ABI between systems.

I'd argue it's more like only 40% of the way to a proper ABI; sizeof(long) varying on the same CPU architecture is just horrible. Sure, it wasn't meant to be an ABI, but, well, it is. And we're stuck with it. And oh how nice would it be if we weren't.

> sizeof(long) varying on the same CPU architecture is just horrible.

On the other hand, `sizeof (int8_t)` is the same size no matter which architecture you are running on.

If you, as the programmer, are depending on the bit-width of an integer type, C has got you covered mostly.

i mean, if sizeof(int8_t) varied, noone would even try to use C as a lingua franca. I, as the programmer, would never expose unknown width integer types, but other things still will, and I'll be forced to interact with them. Allowing such things to even be present in an ABI is just horrible.

> On the other hand, `sizeof (int8_t)` is the same size no matter which architecture you are running on.

EDIT: See account42's reply below.

ORIGINAL COMMENT: No, it's not. CHAR_BIT is not required to be 8 and sizeof (int8_t) is not required to be 1. Hell, int8_t is not even required to be present in <stdint.h>, but int_least8_t is.

huh, I guess that's still not hard-coded. But a non-8-bit-byte system probably runs near nothing to interface with anyway, and would definitely need a completely separate ABI in any scenario.

CHAR_BIT is required to be at least 8, int8_t is required to be exactly 8 bits if present, sizeof(int8_t) is required to return an integer size where sizeof(char) is 1. Hence, if int8_t is present then CHAR_BIT must be 8 and sizeof(int8_t) == 1.

To add a teeny bit to this, POSIX specifies CHAR_BIT must be 8, but C defines it as >= 8.

Reply on news.ycombinator.com