3 ms·
A lot of the comments here are saying that C not having a well-defined ABI is acceptable/good. For people writing C, yes, that may very well be a good thing. Bu
by dzaima 5y ago
A lot of the comments here are saying that C not having a well-defined ABI is acceptable/good. For people writing C, yes, that may very well be a good thing. But as the article states, pretty much every single language must interface with C to be usable, and, for them, it means either calling out to clang/gcc/tcc, or going through the mess of transliterating the C ABI of each target to your own language. not fun.
I work on an implementation of a high-level language (implemented in C) that probably less than 100 people have used, and a C FFI has been asked for plenty of times. You can't get around it.
Would some thing other than C being the ABI be better? Who knows. But the current situation just sucks.
edit: I'd like to explicitly note that I like C as a language. But it still makes for a bad ABI, because it wasn't meant to be one, and barely even works as one.
- PaulDavisThe1st 5y agoWhat you're complaining about, as has been pointed out by several people elsewhere, is that actual real world platforms have different C ABIs. This isn't C's problem, it is a problem that C exposes. The C language doesn't define system calls. It doesn't define a lot of things that were either (a) created in C and presented via a C ABI (b) created in something even less universal and presented via a C ABI. Both (a) and (b) were done by people and projects who are not the C language and do not control the C language.