3 ms·

Probably for the same reasons that 1-bit signed int bitfields are UB. I suppose they could have allowed it as you say, but... is there a need?

layer8 4y ago
It creates a special case when you're converting between signed and unsigned _BitInt(N) and you want to abstract over the concrete N.
hvdijk 4y ago
Are they UB? What rule says they are? I would not be surprised by such a rule, but I am not aware of one.
- cryptonector 4y ago
  Oh, it might be implementation-defined rather than undefined behavior. Sorry, I'm not going to look through the spec right now for this.
- ynik 4y ago
  A single-bit bitfield has only a sign bit, no value bits. Prior to C23 there was no guarantee of two's complement, so it was possible that such a field could only hold the value 0.
  - hvdijk 4y ago
    True. And that still doesn't mean the behaviour is undefined, that just means the construct is not useful except on two's complement implementations. Which, even before C23, was all of them: the C23 change to require two's complement wasn't really meant to invalidate existing implementations, it was meant to reflect the reality that there were no other implementations worth considering. See https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm, the only non-two's-complement implementation still in use that was found was very much a legacy-only thing for backwards compatibility where it was not expected that its users would want a modern C compiler anyway.
Someone 4y ago
FWIW, https://en.cppreference.com/w/cpp/language/bit_field https://en.cppreference.com/w/cpp/language/bit_field doesn’t mention that. It does say bitfields of size zero are allowed (that forces padding to the size of the allocation unit), and also, curiously, says that, in C, “whether int bit-fields that are not explicitly signed or unsigned are signed or unsigned is implementation-defined.”

layer8 4y ago

It creates a special case when you're converting between signed and unsigned _BitInt(N) and you want to abstract over the concrete N.

hvdijk 4y ago

Are they UB? What rule says they are? I would not be surprised by such a rule, but I am not aware of one.

cryptonector 4y ago
Oh, it might be implementation-defined rather than undefined behavior. Sorry, I'm not going to look through the spec right now for this.
ynik 4y ago
A single-bit bitfield has only a sign bit, no value bits. Prior to C23 there was no guarantee of two's complement, so it was possible that such a field could only hold the value 0.
- hvdijk 4y ago
  True. And that still doesn't mean the behaviour is undefined, that just means the construct is not useful except on two's complement implementations. Which, even before C23, was all of them: the C23 change to require two's complement wasn't really meant to invalidate existing implementations, it was meant to reflect the reality that there were no other implementations worth considering. See https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2218.htm, the only non-two's-complement implementation still in use that was found was very much a legacy-only thing for backwards compatibility where it was not expected that its users would want a modern C compiler anyway.

Someone 4y ago

FWIW, https://en.cppreference.com/w/cpp/language/bit_field https://en.cppreference.com/w/cpp/language/bit_field doesn’t mention that. It does say bitfields of size zero are allowed (that forces padding to the size of the allocation unit), and also, curiously, says that, in C, “whether int bit-fields that are not explicitly signed or unsigned are signed or unsigned is implementation-defined.”