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 58 minutes 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 51 minutes 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 44 minutes ago [-]
Many do, contrary to what many C advocates talk about.
Apparently reducing the language to what is in the spec is only a thing when talking about C and to some extent C++.
When other languages have compiler specific extensions beyond the spec, it is a failure in their design.
Yet when C and C++ devs have to reach out to compiler specific extensions, it is not a design failure like it is pointed out to others, rather an advantage.
It is also wrong to not apply the same measure when it doesn't suit the message.
uecker 36 minutes ago [-]
Lot of stawman arguments.
embedding-shape 20 minutes ago [-]
Wouldn't be a authentic pjmlp comment unless they shit on C/C++ and/or praise Java/.NET with a bunch of straw-men :)
pjmlp 8 minutes ago [-]
How wrong you are, C++ isn't in the same league as C, Microsoft was right not wanting to keep updating their C support.
It was already outdated by the time Borland released Turbo C++ 1.0 for MS-DOS, and only got new wind thanks to GNU FOSS and their manifest to prefer C as the main compiled language for GNU projects.
Everywhere else outside UNIX, was going with a mix of C++ for OS frameworks, Apple, Microsoft, IBM, Be, Nokia, Epoch,....
Naturally given the option, between C, C++ and something else I might prefer that something else, however I managed a few interesting positions exactly due to my C++ skills, and interests.
So don't mix my preferences for C and C++ on the same basket.
embedding-shape 6 minutes ago [-]
Wouldn't trade it for anything <3 Enjoy your Tuesday mate :)
pjmlp 7 minutes ago [-]
Really?! That is how many in C circles, including your regular comments to my comments happen to be like.
Two measures two weights, in C versus other systems languages.
FooBarWidget 8 minutes ago [-]
> Not every high-level language gives you byte-level access to the representation of memory objects.
Any code that ventures anywhere near that territory is 99% Undefined Behavior. It's almost impossible to write proper C/C++ code that isn't UB while touching byte-level representations.
uecker 6 minutes ago [-]
This is certainly not true. Accessing bytes of objects is well-defined in C.
wren6991 44 minutes 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".
Thousands of words that boil down to "intmax_t isn't ABI-stable". Who knew? (Everybody.)
aw1621107 1 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.
The mechanism actually does not solve the problem it claims to solve.
aw1621107 46 minutes ago [-]
How so?
pdw 19 minutes ago [-]
Because it imagines that no library other than libc has an ABI that depends on intmax_t.
Suppose I have a libfoo that has a public function that takes an intmax_t parameter. Or that has a public struct with an intmax_t field. It will be compiled for a particular definition of intmax_t. If you try to link it with a program that uses a different definition, it will fail.
The article's solution with the "MY_LIBC_NEW_CODE" define cannot work because no existing C code knows about "MY_LIBC_NEW_CODE".
The proposed mechanism is somewhat useful to a library that wants to provide multiple incompatible implementations of a function. (But this is mostly only interesting for libc implementations that need to handle historic incompatibilities between all the various Unix specs. Other libraries can just give their new, incompatible function a new name.) It's useless if you want to make an incompatible change to a type definition.
uecker 34 minutes ago [-]
The issue is that a programmer is allowed to declare a function on its own without including the header, but then a function aliasing feature would not be visible and does not help. But if we waived this allowance, then a simple macro would do the job as well.
pjmlp 43 minutes 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.
jdw64 2 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
Rendered at 10:34:50 GMT+0000 (Coordinated Universal Time) with Vercel.
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.
But it is also wrong to reduce a language to what is in the spec.
Apparently reducing the language to what is in the spec is only a thing when talking about C and to some extent C++.
When other languages have compiler specific extensions beyond the spec, it is a failure in their design.
Yet when C and C++ devs have to reach out to compiler specific extensions, it is not a design failure like it is pointed out to others, rather an advantage.
It is also wrong to not apply the same measure when it doesn't suit the message.
It was already outdated by the time Borland released Turbo C++ 1.0 for MS-DOS, and only got new wind thanks to GNU FOSS and their manifest to prefer C as the main compiled language for GNU projects.
Everywhere else outside UNIX, was going with a mix of C++ for OS frameworks, Apple, Microsoft, IBM, Be, Nokia, Epoch,....
Naturally given the option, between C, C++ and something else I might prefer that something else, however I managed a few interesting positions exactly due to my C++ skills, and interests.
So don't mix my preferences for C and C++ on the same basket.
Two measures two weights, in C versus other systems languages.
Any code that ventures anywhere near that territory is 99% Undefined Behavior. It's almost impossible to write proper C/C++ code that isn't UB while touching byte-level representations.
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".
- 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)
> 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
Suppose I have a libfoo that has a public function that takes an intmax_t parameter. Or that has a public struct with an intmax_t field. It will be compiled for a particular definition of intmax_t. If you try to link it with a program that uses a different definition, it will fail.
The article's solution with the "MY_LIBC_NEW_CODE" define cannot work because no existing C code knows about "MY_LIBC_NEW_CODE".
The proposed mechanism is somewhat useful to a library that wants to provide multiple incompatible implementations of a function. (But this is mostly only interesting for libc implementations that need to handle historic incompatibilities between all the various Unix specs. Other libraries can just give their new, incompatible function a new name.) It's useless if you want to make an incompatible change to a type definition.
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
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.