4 ms·

There is apparently a bunch of dsps and small hw that has char bit at 16 or 32. Someone would have to tell them that they’re compilers are no longer conformin

There is apparently a bunch of dsps and small hw that has char bit at 16 or 32. Someone would have to tell them that they’re compilers are no longer conforming

stephc_int13 4y ago
This is where the standard should have been more strict. For historical reasons the original C types bit-width were not strongly defined as most hardware of the time had "exotic" registers and addresses by today standards. But it was a long time ago. It is reasonably safe to assume that 14bits ints and 21bits pointers are deprecated. Why would DSPs would need to change the bit-width of chars? We already have shorts and ints that are better candidates for 16bits and 32bits width. I would not mind if the C standard was made both stricter and simpler, and I maintain that the author is wrong, fputc (and all other IO libs depending on it) should not be modified to take into account this kind of absurd corner cases. Doing so will introduce more bugs and complexity that would have to be maintained.
- beached_whale 4y ago
  Because char is loaded here. It is the minimum addressable bit size. So they need to do it because it is faster and cheaper to address larger chunks. The issue in the article is that calls to fputc/fwrite to a binary file will truncate to 8bits still on some of those platforms. A byte type that is always 8bits would be a better approach, i think. But c++ bungled this too, it is the size of a char still. I dont think it should exist on systems that cannot address 8bits
  - stephc_int13 4y ago
    Either the char type should not exist on hardware that can't address 8bits, or better yet, the compiler can help with like 2-3 asm instructions instead of one. Slower, maybe, but saner and conformant to a pre-existing standard.
- adrian_b 4y ago
  "char" is supposed to match the smallest addressable object in the memory, which is why "sizeof" returns the ratio between the size of an object and the size of "char". So if a DSP cannot address bytes separately, but it can address 16-bit words, the size of a "char" must be 16 bits. This is independent of choosing to define "short" as a 16-bit integer. It is useful to have a type corresponding to the smallest addressable part of the memory, but it should not have been named "char", which is a name that should have been reserved for ASCII or UTF-8 data, and never used for numbers or bit strings.
  - stephc_int13 4y ago
    If the hardware can't directly write or read 8-bit chars in memory, it is easy to solve by the compiler with some bit masks, not by creating an artificial CHAR_BIT constraint that will annoy every other implementers down the line. This is beyond ridiculous.
    - dezgeg 4y ago
      There is even some precedent, for example original Alpha AXP instruction set only supports 32-bit and 64-bit memory reads/writes, while still having 8-bit char. Although, I guess the bigger problem is to how to represent pointers to 8-bit values - on Alpha a pointer with value 1 would point to the octet at offset 1 in memory, where presumably on this 16-bit DSP such 1-pointer would point at the octet at offset 2.

There is apparently a bunch of dsps and small hw that has char bit at 16 or 32. Someone would have to tell them that they’re compilers are no longer conforming

stephc_int13 4y ago

This is where the standard should have been more strict. For historical reasons the original C types bit-width were not strongly defined as most hardware of the time had "exotic" registers and addresses by today standards. But it was a long time ago. It is reasonably safe to assume that 14bits ints and 21bits pointers are deprecated. Why would DSPs would need to change the bit-width of chars? We already have shorts and ints that are better candidates for 16bits and 32bits width. I would not mind if the C standard was made both stricter and simpler, and I maintain that the author is wrong, fputc (and all other IO libs depending on it) should not be modified to take into account this kind of absurd corner cases. Doing so will introduce more bugs and complexity that would have to be maintained.

beached_whale 4y ago
Because char is loaded here. It is the minimum addressable bit size. So they need to do it because it is faster and cheaper to address larger chunks. The issue in the article is that calls to fputc/fwrite to a binary file will truncate to 8bits still on some of those platforms. A byte type that is always 8bits would be a better approach, i think. But c++ bungled this too, it is the size of a char still. I dont think it should exist on systems that cannot address 8bits
- stephc_int13 4y ago
  Either the char type should not exist on hardware that can't address 8bits, or better yet, the compiler can help with like 2-3 asm instructions instead of one. Slower, maybe, but saner and conformant to a pre-existing standard.
adrian_b 4y ago
"char" is supposed to match the smallest addressable object in the memory, which is why "sizeof" returns the ratio between the size of an object and the size of "char". So if a DSP cannot address bytes separately, but it can address 16-bit words, the size of a "char" must be 16 bits. This is independent of choosing to define "short" as a 16-bit integer. It is useful to have a type corresponding to the smallest addressable part of the memory, but it should not have been named "char", which is a name that should have been reserved for ASCII or UTF-8 data, and never used for numbers or bit strings.
- stephc_int13 4y ago
  If the hardware can't directly write or read 8-bit chars in memory, it is easy to solve by the compiler with some bit masks, not by creating an artificial CHAR_BIT constraint that will annoy every other implementers down the line. This is beyond ridiculous.
  - dezgeg 4y ago
    There is even some precedent, for example original Alpha AXP instruction set only supports 32-bit and 64-bit memory reads/writes, while still having 8-bit char. Although, I guess the bigger problem is to how to represent pointers to 8-bit values - on Alpha a pointer with value 1 would point to the octet at offset 1 in memory, where presumably on this 16-bit DSP such 1-pointer would point at the octet at offset 2.