On 03/09/2025 21:12, Oliver Hunt wrote:
>
>
>> On Sep 3, 2025, at 7:31 AM, David Brown via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>>
>>
>> On 03/09/2025 15:36, Tiago Freire wrote:
>>>>> What says who? What guarantees your compiler when you specify _BitInt(9) to go "nah he wants a specialized 9bit FPGA register" instead of just giving you a 16bit register with 7 unused bits?
>>>> That will be up to the compiler.
>>> Precisely! It's going to choose whatever, not what you whished it would have been.
>>> It's Voodoo programming.
>>
>> No, that kind of thing will be implementation-defined behaviour. It is up to the compiler, but will be fixed and should be documented. It's the same for countless other things in C and C++ that you rely on every day, such as the size of "int" or your favourite, alignment requirements.
>
>
> Sorry, I’m confused right now - I thought you were arguing that these things should be UB? If something is UB it’s not implementation defined, it’s UB.
>

My apologies if the confusion was my fault (and since communication is a
cooperative process, it is surely at least partly my fault).

Overflow behaviour for signed _BitInt arithmetic should be UB, just like
for all other signed integer types.

Alignment requirements for _BitInt types should be
implementation-defined, just like alignment requirements for all other
types. (C23 specifies how they must match alignments of certain other
types, and C++ should follow that, but those other types have
implementation-defined alignments.)