> Well, you can only get the exact sizes on platforms that support those exact sizes. On other platforms, the _BitInt types need to be contained in something larger if they are cannot be provided directly. So a _BitInt(9) is likely to need an FPGA or special hardware for its size to be exactly 9 bits. But they can be implemented in an obvious way on other platforms, just with padding bits. Alignment will be implementation dependent, just as it is for all other types.

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?


> How can something that is not yet a feature of the language, have "always" been UB?

It already exists in C. That the argument, whatever C is doing C++ will adopt for interoperability, there is no room for alternative behavior here.


> Alignment is not an issue when converting anything. Converting between types is done by value. Alignment only matters for pointers.
> And the alignment of different types is not UB, it is implementation-defined behaviour.

What? It applies to operations on "values".
Why do think there exists such a thing as an alignment requirement?
If it's not a register or is part of the instruction. EVERYTHING is in memory and has an address.
You can't emit an instruction to operate on your "values" (which are in memory and therefore referenced in assembly by an address) because that is out of spec for the hardware. And because you can't control exactly what instructions your compiler is going to emit, it's not "implementation-defined", it's undefined. Nobody knows what's going to happen.
This is not how computers work.

That's why when you say things like "When you are dealing with hardware with 9-bit integers, or an SHA accelerator with 384-bit registers, you want types that have the exact size."
And I ask "How does _BitInt(384) operate on SHA accelerator with 384-bit registers when it's not aligned?", and now you are telling me "It doesn't! We just copy it over to a type that does."...what are we talking about?

Do you see the problem?

-----Original Message-----
From: David Brown <david.brown_at_hesbynett.no>
Sent: Tuesday, September 2, 2025 23:17
To: Tiago Freire <tmiguelf_at_[hidden]>; std-proposals_at_lists.isocpp.org
Subject: Re: [std-proposals] D3666R0 Bit-precise integers



On 02/09/2025 18:38, Tiago Freire wrote:
> See here's my problem:
>
>> When you are dealing with hardware with 9-bit integers, or an SHA accelerator with 384-bit registers, you want types that have the exact size.
>
>> Ultimately, this will be implementation-dependent. But it seems
>> natural (to me) that alignment of a _BitInt should normally be that
>> of the any standard unsigned integer type that can contain them, or
>> uint64_t for larger _BitInt's. (That's what C23 does.)
>
> These 2 statements are contradictory. It is either one or the other and it can't be both.

Well, you can only get the exact sizes on platforms that support those exact sizes. On other platforms, the _BitInt types need to be contained in something larger if they are cannot be provided directly. So a
_BitInt(9) is likely to need an FPGA or special hardware for its size to be exactly 9 bits. But they can be implemented in an obvious way on other platforms, just with padding bits. Alignment will be implementation dependent, just as it is for all other types.

> The real answer is actually neither, this is actually UB. It's all UB, it always has been.

How can something that is not yet a feature of the language, have "always" been UB?

> Since alignment is not specified converting it to anything is UB.

Alignment is not an issue when converting anything. Converting between types is done by value. Alignment only matters for pointers.

And the alignment of different types is not UB, it is implementation-defined behaviour.

> Maybe it works on some hardware that are tolerant with alignment, and some implementations may try to align with what you probably want to do anyways, but it's still UB.
>

_BitInt types would always be accessed via pointers that are appropriately aligned, unless you are playing silly buggers with converting pointer types - just like for all other types.

> You want to work with specialized registers? The best way is for the compiler to provide concrete types that satisfy both the size and alignment requirements for those registers.

If you have hardware that works best with types of a particular bit size, why not have standardised types that are of that particular bit size - to the best of the target implementation's abilities?

> You can't just use a _BitInt and expect it to align because it doesn't have too, and according to you own words it can't be used for larger specialized registers, that's what you and everyone wants to do but that is not what it actually does.
>

Why would you not have to have appropriate alignment for _BitInt types?

> That's why I picked that example. It's either a chunky boy or it doesn't align, the end.
>

For C23 _BitInt, _BitInt(512) will have the same alignment as uint64_t.
I would expect the same for C++ _BitInt.