Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: _BitInt(N)
Date: Mon, 24 Nov 2025 05:33:03 -0800
Organization: None to speak of
Lines: 78
Message-ID: <87y0nv369c.fsf@example.invalid>
References: <10dajlh$ko3c$1@dont-email.me> <10fus62$hl69$1@solani.org> <10fv2dm$3can9$1@paganini.bofh.team> <10fv40v$1f7a2$1@dont-email.me> <87ms4c4bom.fsf@example.invalid> <10g08vm$1us25$1@dont-email.me> <10g1et7$2bmus$1@dont-email.me> <10g1j7h$2deh9$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Mon, 24 Nov 2025 13:33:04 +0000 (UTC)
Injection-Info: dont-email.me; posting-host="497198ffef236bf75350d11e6379045b"; logging-data="2535543"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+nU1k3th4c8xKLDfY3jS5R"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:q4jcqlgPzKoSmRVk5BBRxzTKix8= sha1:7OMBf4eoJD1tal3HUeerbE+PX6I=
Xref: csiph.com comp.lang.c:395415

bart <bc@freeuk.com> writes:
> On 24/11/2025 11:17, David Brown wrote:
>> On 24/11/2025 01:30, bart wrote:
>>> Saving memory was mentioned. To achieve that means having bitfields
>>> that may not start at bit 0 of a byte, and may cross byte- or word-
>>> boundaries.
>>>
>> No, that is incorrect.
>> The proposal mentions saving /space/ as relevant in FPGAs - not
>> saving / memory/.
>
> But I was responding to a suggestion here that one use of _BitInts -
> presumably for ordinary hardware - was to save memory.

That's *your* presumption.

The rationale section of N2709 mentions performance/space concerns only
in the context of FPGAs.

Packing arrays on ordinary hardware is impractical given C's memory
model.

[...]

> What about arrays of _BitInt(1), _BitInt(2) and _BitInt(4)? These
> could actually be practically implemented, with a few restrictions,
> and could save a lot of memory.

No, they couldn't.  Array indexing is defined in terms of pointer
arithmetic, and you can't have a pointer to something smaller than one
byte.

<OT>I can see something this being done in C++ with operator
overloading.  See, for example, the std::vector<bool> partial
specialization.</OT>

[...]

> In my 391-bit example, the top 7 bits will be within a 64-bit
> word. What values will those extra 57 bits be?

Probably 0.

> Taking just those 7 bits by themselves, if the value is 1111111, that is:
>   00000000'00000000'00000000'00000000'00000000'00000000'00000000'01111111)
>
> and you do an arithmetic right shift, then you will get 0111111 not
>
> 1111111, since the hardware sign bit is bit 63 not bit 6. It needs
> more work.

Yes, the compiler has to do some extra work for types with padding bits,
to ensure that those bits are either set to 0 or properly ignored.

[...]

> No, I stand by it. There are even different levels of ridiculousness:
> expecting a language to support a huge fixed integer type like
> int1000000_t (when C only acquired 8/16/32/64-bit types in C99, and
> those still aren't built-in).
>
> And allowing random sizes such as int817838_t. (See, it seems much
> sillier using this syntax!)

Your complaint seems to be that the feature is too flexible.

> For such sizes it makes much more sense to acknowledge the existence
> of arbitrary-precision support, so that the equivalents of
> int1000000_t and int817838_t would be compatible types. Or you can
> forget specific widths and just have the one bigint type.

Yes, there are a lot of things that C23 *could* have done, but didn't.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */