Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: _BitInt(N) Date: Mon, 24 Nov 2025 16:46:32 -0800 Organization: None to speak of Lines: 72 Message-ID: <87pl972b2v.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> <87y0nv369c.fsf@example.invalid> <10g1qpu$2fi66$2@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Tue, 25 Nov 2025 00:46:33 +0000 (UTC) Injection-Info: dont-email.me; posting-host="fa7a31f1160d6b9aea861ca62102f1fd"; logging-data="3113762"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/MzEwgoKsYX9nzOQsO0Lnx" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:SC8vVpcvqzyj8fObX2NDz2ya1I0= sha1:kK0Z8N68BkRBsEMNJW1Y8UjVUZ0= Xref: csiph.com comp.lang.c:395445 bart writes: > On 24/11/2025 13:33, Keith Thompson wrote: >> bart writes: > >>> 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. > > The restrictions I mentioned were to do with pointers to individual bits. Right. C doesn't have pointers to individual bits. > It is possible that operations such as: > > x = A[i] > A[i] = x > > can be well defined when A is an array of 1/2/4-bit values, even if > expressed like this: > > *(A + i) Not in C as it's currently defined. > But this would have to be indivisible when A is such an array: only > the whole thing is valid, not (A + i) by itself, or A by itself; you'd > need &A. > > This would need a small tweak to the language, but that is nothing > compared to supporting (i3783467 * i999 / i3) >> i17. It would hardly be a "small tweak". I can imagine some future version of C adding support for indexing packed arrays, but I don't think it would have been worthwhile just so that large arrays of small _BitInts can be stored more efficiently. Doing that on ordinary hardware was not part of the rationale for C23's bit-precise integer types, and I haven't seen any such proposals for C2y. And assuming that "(i3783467 * i999 / i3) >> i17" means what I think it means, huge bit-precise integers are already standard (they're part of C23), and the work of implementing them is largely done in gcc and llvm/clang. > But I write a script in my dynamic language, [...] > C can only get down to that u8 figure (100MB) using its 'char' > type. Even 'bool' doesn't make it smaller (presumably for the reasons > you mentioned). > > You are forced to emulate such arrays in user-code using shifts and masks. Yes. C doesn't support packed arrays, and is unlikely to do so any time in the near future. C23 added a feature that doesn't do everything you want it to do. You can of course implement such things in a library, but the syntax for using it would probably be a bit ugly. And in fact at least one person has done so. (I've known about this for about a minute, so I have no comment other than that it exists.) https://github.com/gpakosz/PackedArray/ -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */