From: david.brown@hesbynett.no
On 24/11/2025 12:44, Michael S wrote:
> On Mon, 24 Nov 2025 12:17:58 +0100
> David Brown wrote:
>>
>> The proposal is not about saving /memory/. It specifically says that
>> a _BitInt(N) has the same size and alignment as the smallest basic
>> type that can contain it, until you get to N greater than 64-bit, in
>> which they are contained in an array of int64_t. (The reality is a
>> little more formal, to handle targets that have other sizes of their
>> basic types.)
>>
>
> That is a bit unfortunate.
> Compiler support for arrays of 17 to 24bit numbers packed as 3 octet
> per item would have been handy. And not hard at all for compiler to
> implement, at least on architectures that has proper support for
> unaligned access, like x86, POWER, Arm and RISC-V.
>
> I certainly have real-world applications that use packed arrays like
> that. They could have been written in cleaner and less error-prone
> way if such feature was available.
>
> I suppose, packed numeric arrays with 5, 6 or 7 octets per item are also
> used by some people, although they are probably less common than my
> case.
>
There may certainly be use-cases for such "packed arrays", but I think
that would just add complications to the definitions of _BitInt and
require more implementation-specific behaviour. And then someone would
insist that they be packed by bit, rather than by byte, and cause all
the problems that Bart feared.
I think this kind of thing is probably best left to
implementation-specific features - just like "packed" attributes and
pragmas today.
Alternatively, a standardised syntax for detailed control of packing and
ordering in structs, arrays, and especially bit-fields, could be
developed and added to the standards. I don't see a good reason to
handle _BitInt's differently.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
