5 ms·

IMO one of the most disappointing things about C: it smells like it should be a straightforward translation to assembly, but actually completely is not because

IMO one of the most disappointing things about C: it smells like it should be a straightforward translation to assembly, but actually completely is not because of the "virtual machine" magic the Standard uses which opens the door to almost anything. Oh you would like a byte? Is that going to be a 7 bit, 8 bit, 12 bit, or 64 bit byte? It's not specified, yay! Have fun trying to write robust code.

HeliumHydride 2y ago
C++ has made efforts to fix some of this. Recently, they enforced that signed integers must be two's complement. There is a proposal currently to fix the size of bytes to 8 bits.
- ratmeadow 2y ago
  Yes, which is excellent (although 50 years too late, I'll try not to be too cynical...). The problem is that C++ is a huge language which is complex and surely not easy to implement. If I want a small, easy language for my next microprocessor project, it probably won't be C++20. It seems like C is a good fit, but really it's not because it's a high level language with a myriad of weird semantics. AFAIK we don't have a simple "portable assembler + a few niceties" language. We either use assembly (too low level), or C (slightly too high level and full of junk).
bobmcnamara 2y ago
Ahem, it's specified to not be 7.
tialaramex 2y ago
Abstract. It's an Abstract machine, not a Virtual machine.
zajio1am 2y ago
Size of byte is implementation-defined, not unspecified. Why is that a problem for writing robust code? It is okay to assume implementation-defined behavior as long as you are targeting a subset of systems where these assumptions hold, and if you check them at build-time.
keldaris 2y ago
Luckily, little of it matters if you simply write C for your actual target platforms, whatever they may be. C thankfully discourages the very notion of "general purpose" code, so unless you're writing a compiler, I've never really understood why some C programmers actually care about the standard as such. In reality, if you're writing C in 2025, you have a finite set of specific target platforms and a finite set of compilers you care about. Those are what matter. Whether my code is robust with respect to some 80s hardware that did weird things with integers, I have no idea and really couldn't care less.
- msla 2y ago
  > I've never really understood why some C programmers actually care about the standard as such. Because I want the next version of the compiler to agree with me about what my code means. The standard is an agreement: If you write code which conforms to it, the compiler will agree with you about what it means and not, say, optimize your important conditionals away because some "Can't Happen" optimization was triggered and the "dead" code got removed. This gets rather important as compilers get better about optimization.
  - uecker 2y ago
    True, we are currently eliminating a lot of UB from the future C standard to avoid compilers breaking more code. Still, while I acknowledge that this is a real issue, in practice I find my C code from 30 years ago still working. It is also a bit the fault of users. Why favor so many user the most aggressive optimizing compilers? Every user filing bugs or complaining about aggressive optimizing breaking code in the bug tracker, very user asking for better warnings, would help us a lot pushing back on this. But if users prefer compiler A over compiler B when you a 1% improvement in some irrelevant benchmark, it is difficult to argue that this is not exactly what they want.
    - bobmcnamara 2y ago
      Sadly, at least in the embedded space some of us still deal with platforms where the proprietary core vendor's compiler routinely beats open source compiler cycle counts by a factor of 1.5 to 3. The big weak region seems to be in-order machines with smaller numbers of general purpose registers. GCC at least seems to do its basic block planning entirely before register allocation with no feedback between phases.
uecker 2y ago
No, it has to be at least 8 and this is sufficient to write portable code.

HeliumHydride 2y ago

C++ has made efforts to fix some of this. Recently, they enforced that signed integers must be two's complement. There is a proposal currently to fix the size of bytes to 8 bits.

ratmeadow 2y ago
Yes, which is excellent (although 50 years too late, I'll try not to be too cynical...). The problem is that C++ is a huge language which is complex and surely not easy to implement. If I want a small, easy language for my next microprocessor project, it probably won't be C++20. It seems like C is a good fit, but really it's not because it's a high level language with a myriad of weird semantics. AFAIK we don't have a simple "portable assembler + a few niceties" language. We either use assembly (too low level), or C (slightly too high level and full of junk).

bobmcnamara 2y ago

Ahem, it's specified to not be 7.

tialaramex 2y ago

Abstract. It's an Abstract machine, not a Virtual machine.

zajio1am 2y ago

Size of byte is implementation-defined, not unspecified. Why is that a problem for writing robust code? It is okay to assume implementation-defined behavior as long as you are targeting a subset of systems where these assumptions hold, and if you check them at build-time.

keldaris 2y ago

Luckily, little of it matters if you simply write C for your actual target platforms, whatever they may be. C thankfully discourages the very notion of "general purpose" code, so unless you're writing a compiler, I've never really understood why some C programmers actually care about the standard as such. In reality, if you're writing C in 2025, you have a finite set of specific target platforms and a finite set of compilers you care about. Those are what matter. Whether my code is robust with respect to some 80s hardware that did weird things with integers, I have no idea and really couldn't care less.

msla 2y ago
> I've never really understood why some C programmers actually care about the standard as such. Because I want the next version of the compiler to agree with me about what my code means. The standard is an agreement: If you write code which conforms to it, the compiler will agree with you about what it means and not, say, optimize your important conditionals away because some "Can't Happen" optimization was triggered and the "dead" code got removed. This gets rather important as compilers get better about optimization.
- uecker 2y ago
  True, we are currently eliminating a lot of UB from the future C standard to avoid compilers breaking more code. Still, while I acknowledge that this is a real issue, in practice I find my C code from 30 years ago still working. It is also a bit the fault of users. Why favor so many user the most aggressive optimizing compilers? Every user filing bugs or complaining about aggressive optimizing breaking code in the bug tracker, very user asking for better warnings, would help us a lot pushing back on this. But if users prefer compiler A over compiler B when you a 1% improvement in some irrelevant benchmark, it is difficult to argue that this is not exactly what they want.
  - bobmcnamara 2y ago
    Sadly, at least in the embedded space some of us still deal with platforms where the proprietary core vendor's compiler routinely beats open source compiler cycle counts by a factor of 1.5 to 3. The big weak region seems to be in-order machines with smaller numbers of general purpose registers. GCC at least seems to do its basic block planning entirely before register allocation with no feedback between phases.

uecker 2y ago

No, it has to be at least 8 and this is sufficient to write portable code.