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/>