Hi Joseph,

On 12/30/22 21:38, Joseph Myers wrote:
On Fri, 30 Dec 2022, Alejandro Colomar via Gcc wrote:

I was wondering if there was any reason to make that UB in the standard, when
unsigned wrapping has always been well-defined, and this is a case that is
likely to be implemented with some operation that wraps around, right?  I

It's likely to be implemented by a shift, that might be by the number of
bits in the argument in the overflow case, and shift by the width of the
argument is undefined behavior; some architectures wrap the shift count
modulo the width (do you actually want 1 or 0 as the result of
stdc_bit_ceil?), some wrap the shift count modulo a larger value (e.g.
treating 1 << 32 as 0 but 1 << 64 as 1) and for some architectures the
result depends on the particular shift instruction used (meaning undefined
behavior on the form of the result of an integer expression possibly
comparing unequal to itself because the compiler duplicated the expression
and then used different instructions to compute it in different places).

For the C standard, shifts have wrap around semantics for unsigned types:

C2x(N3054)::6.5.7p4:

"
The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are filled with zeros. If E1 has an unsigned type, the value of the result is E1 × 2E2, wrapped around. [...]
"

Which reminds me that I forgot to use 1ul << ...

Since the <stdbit.h> functions are only provided for unsigned types, there should be no problems, right?


Would you consider either or both of being more generous in the GNU
implementation and guarantee wrap around, and/or suggest that the standard
guarantees the wrap around?

The CD ballot has closed, and this doesn't appear to be one of the 338
comments raised on that ballot, and I don't really expect time at next
month's meeting to deal with additional technical comments not on that
list, when we have only 15 hours to deal with 338 comments.  Once we have
an issue tracking process for the C standard again (hopefully involving an
issue tracker that the public can readily submit issues in),

Hopefully.  And a public git repository and mailing list would be awesome  :)

*comes back to reality*

I'd suggest
raising such concerns there (unless there's a CD2 ballot; technical
comments are best avoided at a DIS ballot if possible).

Ahh, no problem. If it's something to be suggested for C3x or for a small C2y fix (like C17 was), that would be fine.

Cheers,

Alex




--
<http://www.alejandro-colomar.es/>

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to