N2912 Draft: Inconsistency in Section 6.7.8 (Example 3)

[arnab chatterjee]

Hello all,

In the latest C2x working draft <www.open-std.org/jtc1/sc22/wg14/www/docs/n2912.pdf>, Example 3 in section 6.7.8 (Type definitions) states that "const-qualified bit-field which (if it could be accessed) would contain values in either the range [−15, +15] or [−16, +15]" (this 5-bit field is of type signed int). As the draft also mandates two's complement representation for signed types, I think the range should consistently be [-16, +15].

Or could the different ranges be related to some other clause(s) that I might have missed? Because for another bit-field in the same example, it also says "one named r that contains values in one of the ranges [0, 31], [−15, +15], or [−16, +15]" (r is a 5-bit plain int field; either unsigned or signed). Again the [-15, +15] range seems unnecessary after introducing two's complement requirement.

Regards,
cHaR.

[Richard Damon]

I think the issue is that even with two's complement encoding, the
standard still allows the use of sign bit set and the rest of the bits 0
to be a "trap" representation, and thus the range of valid values be
symmetrical and not include the extra extreame negative value.

[Stephen Heumann]

On 2022-07-16 12:37:51 +0000, Richard Damon said:
>
> I think the issue is that even with two's complement encoding, the
> standard still allows the use of sign bit set and the rest of the bits
> 0 to be a "trap" representation, and thus the range of valid values be
> symmetrical and not include the extra extreame negative value.

Previous C standards allowed that, but draft C23 does not. It looks
like the example in question simply wasn't updated when the standard
was altered to impose the new restrictions -- it was probably just
overlooked. Of course, examples are not normative, so it does not
affect what the standard actually requires.

--
Stephen Heumann