4 ms·

Sorry, you're absolutely right, and I was lazy in my comment. There is indeed a big difference between "undefined" behavior and "implementation-defined" behavi

Sorry, you're absolutely right, and I was lazy in my comment. There is indeed a big difference between "undefined" behavior and "implementation-defined" behavior. For example, there's a lot of spooky "undefined behavior" around dereferencing pointers. In one famous case [1], dereferencing a pointer actually led the compiler to skip a later check on whether the pointer was NULL, because if the pointer was already dereferenced then it must have been valid. Another classic "implementation-defined" detail is what is the size of a "char"? Nowadays we can readily assume it's 8 bits, but that wasn't so guaranteed when C was written! [1] https://lwn.net/Articles/342330/ https://lwn.net/Articles/342330/

kevin_thibedeau 5y ago
16-bit chars still persist in DSP land. It is a tribute to C's flexibility that it can easily be implemented for such architectures.
- fsckboy 5y ago
  that's interesting, I've done DSP on paper (and microcode, i'm old school), but never on such an architecture. and it's interesting to think, "well, that's useful, let's make it a defined behavior!" but then that defined behavior could be a nightmare of inefficiency on a machine with a different architecture. (i mean, probably not for the particular case of 16 bit chars, but in the general case quite unpredictable)
  - AceJohnny2 5y ago
    Not really related to C, but I once worked on an SoC where the DSP was mixed 16/24-bit, so they mapped each word to the ARM 32-bit bus. That is, each 4-byte address would map to one 16-byte (or 24-byte) word of the DSP's memory & register space. But under the DSP was an I2C-based ISP that was glued in, and _its_ 8-bit words were mapped to each of the DSP's 16-bit (/24-bit) words. So if the ARM wanted to talk to the ISP's control space, it read one 8-bit word of the ISP in each 32-bit word address. The cherry-on-top was that the DSP was Big-Endian and the ARM was Little-Endian, and so you had to swap all the data you were exchanging with it. Still the biggest HW WTF I've encountered in my career. This was the STMicroelectronics Nomadik 8810/8815/8820 chips. https://en.wikipedia.org/wiki/Nomadik https://en.wikipedia.org/wiki/Nomadik

kevin_thibedeau 5y ago

16-bit chars still persist in DSP land. It is a tribute to C's flexibility that it can easily be implemented for such architectures.

fsckboy 5y ago
that's interesting, I've done DSP on paper (and microcode, i'm old school), but never on such an architecture. and it's interesting to think, "well, that's useful, let's make it a defined behavior!" but then that defined behavior could be a nightmare of inefficiency on a machine with a different architecture. (i mean, probably not for the particular case of 16 bit chars, but in the general case quite unpredictable)
- AceJohnny2 5y ago
  Not really related to C, but I once worked on an SoC where the DSP was mixed 16/24-bit, so they mapped each word to the ARM 32-bit bus. That is, each 4-byte address would map to one 16-byte (or 24-byte) word of the DSP's memory & register space. But under the DSP was an I2C-based ISP that was glued in, and _its_ 8-bit words were mapped to each of the DSP's 16-bit (/24-bit) words. So if the ARM wanted to talk to the ISP's control space, it read one 8-bit word of the ISP in each 32-bit word address. The cherry-on-top was that the DSP was Big-Endian and the ARM was Little-Endian, and so you had to swap all the data you were exchanging with it. Still the biggest HW WTF I've encountered in my career. This was the STMicroelectronics Nomadik 8810/8815/8820 chips. https://en.wikipedia.org/wiki/Nomadik https://en.wikipedia.org/wiki/Nomadik