To Save C, We Must Save ABI (thephd.dev)
62 points by gurjeet 3 days ago
usrnm 3 hours ago
The famous C dilemma: we want to be as close to the machine as possible, but don't want to change anything when the machine changes
pjmlp 2 hours ago
Because contrary to urban myths, C is a normal high level language like everything else.
The Assembly like abilities have been growing as language extensions in specific compilers, not as part of ISO C.
Going back to K&R C, inline Assembly or intrisics were not even available, all of that required using the Assembler directly.
uecker an hour ago
Not every high-level language gives you byte-level access to the representation of memory objects.
But it is also wrong to reduce a language to what is in the spec.
pjmlp an hour ago
FooBarWidget an hour ago
wren6991 an hour ago
Except for the basic integer types. Change those as much as possible. Hell, CHAR_BIT=12 just to keep them on their toes.
Personal pet theory: C is portable as in "you can retarget the compiler to any machine" moreso than "your code will run on any machine".
trashb 27 minutes ago
> Personal pet theory
This is actually how c grew up. This is also one of the reasons why the spec is quite ambiguous in certain locations. C is made to be easily portable not a universal codebase for all platforms (though you can get quite close with some tricks like macros). Remember the spec allows C to run on a Unisys 1100/2200 just as well as on a pdp-11.
I may be to embedded for this but if you want your code to handle long long as int64_t use <stdint.h>. I am of the opinion that you should always use fixed width types as portable types are a huge footgun and kind off redundant.
Especially when you start doing a little more complex things expecting them to work exactly the same, like 128bit values on a 64bit platform.
tonyhart7 2 hours ago
so what they gonna do ??
clbrmbr 5 minutes ago
I was battling GCC… until the new guy (a smart business major) pointed out I could just compile from Lua to ASM directly. Claude was happy to write a compiler over night. :facepalm:
aw1621107 2 hours ago
Previous submissions with comments:
- 2023-06-10, 64 points, 16 comments: (https://news.ycombinator.com/item?id=36249253)
- 2022-03-13, 175 points, 129 comments: (https://news.ycombinator.com/item?id=30660528)
add2 an hour ago
COM-like C ABI saves C++
solar_quick0p 17 minutes ago
Curious. Care to elaborate further?
jdw64 3 hours ago
But the industry ultimately runs on compatibility, so I get why they do it. But if compatibility breaks, wouldn't hardware vendors die out? If you look at PLC and other hardware manufacturers, they're not even using modern coding. They're still running on old code. They say it's 'safe and certified code,' but in reality, it's just legacy code.
Because in hardware, programmers, aside from researchers, are often paid much less and work in worse conditions compared to their software counterparts. At a software company, code is the product itself. But in manufacturing, software is treated as a cost attached to machines worth billions of dollars. While equipment and sensors keep getting updated and more expensive, the people connecting everything are seen as a cost cutting target. So hardware programmers generally have good job security, but their salaries aren't high. In that situation, asking them to learn something new instead of sticking with the old ways usually gets resistance, because they're not being properly compensated for that learning
mschuster91 2 hours ago
> In that situation, asking them to learn something new instead of sticking with the old ways usually gets resistance, because they're not being properly compensated for that learning
And on top of that... these things are battle tested, often running machinery that isn't just worth millions of dollars but runs goods worth orders of magnitude more. Stuff breaking because some new shiny thing has been introduced... no one bats too much an eye when Reddit's UI is missing a widget here and there because someone pushed vibecoded garbage to prod again, but a car manufacturing line? A chemical plant that needs to operate 24/7 so that nothing solidifies in pipes, wrecking the entire facility to the point you need to fully dismantle it?
When this kind of consequences are in the air, everyone is much much more conservative, because no one wants to be left holding that bag.
jdw64 2 hours ago
Exactly. You're in the same industry as me. The moment you try to change something, if the production line stops, the losses are enormous—so everyone becomes conservative. That makes it even harder to change later... It's a really difficult problem
xyzsparetimexyz 2 hours ago
Yeah, well, that didn't happen
codeflo 2 hours ago
Thousands of words that boil down to "intmax_t isn't ABI-stable". Who knew? (Everybody.)
aw1621107 2 hours ago
I think that's somewhat overly reductive. A significant portion (maybe 1/3-1/2?) of the article is devoted to describing mechanisms by which an ABI could be evolved, including a new (?) mechanism implemented in the author's Clang fork and submitted to the C committee ([0] in the blog post, currently on revision 8 [1]). Sure, it isn't a perfect solution, but as the author says:
> at least we’ll finally have the chance to have that discussion [about breaking ABI] with our communities, rather than just being outright denied the opportunity before Day 0.
[0]: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2901.htm
[1]: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3913.htm
uecker 2 hours ago
The mechanism actually does not solve the problem it claims to solve.
aw1621107 an hour ago
pjmlp an hour ago
Not really, because many don't even know there isn't such thing as C ABI, rather the OS ABI, when the OS happens to be written in C.
simiones 11 minutes ago
Even this is too simplistic. While C compilers normally use the OS ABI, there is nothing that requires them to do this, and other languages don't. Of course, when you need to call functions provided by the OS, you have to do so following the OS ABI; but calls between functions written in your own language, even in different libs, don't need to follow this same rule.