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.
The real answer is actually neither, this is actually UB. It's all UB, it always has been.
Since alignment is not specified converting it to anything is UB. 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.

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

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


-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of David Brown via Std-Proposals
Sent: Tuesday, September 2, 2025 09:25
To: std-proposals_at_[hidden]
Cc: David Brown <david.brown_at_hesbynett.no>
Subject: Re: [std-proposals] D3666R0 Bit-precise integers



On 01/09/2025 20:47, Tiago Freire via Std-Proposals wrote:
> My gripe with _BitInt is that it is made for an abstract machine that
> has no real world analogous.
>

_BitInt /does/ have real-world analogues, which is precisely why it was added to C (first as an extension in clang/llvm, then in C23). A major one is for FPGAs and other custom hardware, which is seeing more and more design work being done in higher level languages and sequential languages (like C and C++) rather than traditional hardware design languages (like Verilog and VHDL). 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. _BitInt is not essential for using C or C++ for this kind of work, but it does make it clearer and neater to work with, and it saves you from needing compiler-specific extensions.

Additionally, _BitInt has no integer promotions. This can again make it easier to write portable, efficient and safe low-level code, by removing one of the implementation-dependent aspects of the <stdint.h> fixed-size integer types.

Bit-counted integer types are a natural type for bitfields - especially in low-level and hardware-related coding.

And they can give neater and clearer code for algorithms used in cryptography and compression.

So yes, they have real-world analogues - both in terms of modelling some real-world hardware, and in modelling some real-world software needs.

> ints don't have just size but also alignment properties.
> what should the alignment of _BitInt(512) should be?
> Should it align to the cache line? or should it align with the
> requirements for the largest implementable operand to save on space?
>

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.)
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals