You can also do this:

auto val = compute_sha(...);

making _BitInt useless, don't need it, I just need whatever the actual concrete type "compute_sha" is returning.
You haven't so much "got a type to be able to compute sha 384" but more like "look at this type that I used to copy data into".

> "The machine" is relevant to that conversation, but only to the extent that we can ensure that `_BitInt`'s definition does not prevent the compiler/machine from providing optimizations that the user needs.

But that's precisely my point. _BitInt is a concept that is disconnected from any machine that actually exists.
It doesn't matter how you interpret your programming language, the compiler cannot magically make the machine do something that it can't physically do just because that's how you coded it.


-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Jason McKesson via Std-Proposals
Sent: Wednesday, September 3, 2025 19:16
To: std-proposals_at_[hidden]pp.org
Cc: Jason McKesson <jmckesson_at_[hidden]>
Subject: Re: [std-proposals] D3666R0 Bit-precise integers

On Wed, Sep 3, 2025 at 12:24 PM Tiago Freire via Std-Proposals <std-proposals_at_lists.isocpp.org> wrote:
>
> > No one has mentioned aliasing! You can't suddenly jump in with a different topic entirely and pretend that's what you were talking about all along.
>
> This isn't a gotcha conversation. This really should be very easy to understand.
>
> This is what you said of _BitInt
>
> > 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 this:
>
> > But it seems natural (to me) that alignment of a _BitInt should
> > normally be [...] uint64_t for larger _BitInt's. (That's what C23
> > does.)
>
> Let's focus on sha registers.
> What is the alignment of this variable?
> _BitInt(384) shaBuffer; //< This one
>
> If statement number 2 is true, the answer is 8Bytes, then the statement 1 is wrong. You can't use _BitInt(384) to represent that specialized register because it needs an alignment of 64Bytes.
> If the answer is 64Bytes then not only statement 2 is false, it is also incompatible with C.
> Does it have an alignment of 8Bytes or 64Bytes? It can't be both!
>
> And this thing where you associate a "_BitInt(384)" to a "sha384 register" is called aliasing!
>
>
> > No one is suggesting that _BitInt types should alias other types, or that people will assume they alias other types.
>
> When you say "_BitInt(384)" can be used for "SHA accelerator with 384-bit registers", that's exactly what it means.

"Alias" in the context of the C++ standard has a very clear meaning.
It's when you access an object with a pointer/reference to a type which is different from the actual type of that object. That is, you have an `int` object and you cast a pointer/reference to it to a `float` and then try to access it.

To use a 384-bit integer in an "SHA accelerator with 384-bit registers" does not require aliasing it; it's simply a use of a value.
It's just this:

```
_BitInt(384) val = compute_sha(...);
```

There: `val` is now allowed to be in a 384-bit register. No aliasing, as defined by the C++ standard, is required to achieve this.

> The rest of the explanation of values/objects are just wrong. A description of the language is not a description of the machine.

The disconnect here is that you are talking about what "the machine"
might do, while we are talking about what "the language" should be.

"The machine" is relevant to that conversation, but only to the extent that we can ensure that `_BitInt`'s definition does not prevent the compiler/machine from providing optimizations that the user needs.
Beyond that, "the machine"'s notion of "value" and "object" are irrelevant.
--
Std-Proposals mailing list
Std-Proposals_at_lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals