On Tue, Jan 27, 2026 at 02:40:03PM +0000, Lorenzo Stoakes wrote:
> On Tue, Jan 27, 2026 at 08:53:44AM -0500, Yury Norov wrote:
> > On Thu, Jan 22, 2026 at 04:06:09PM +0000, Lorenzo Stoakes wrote:
...
> > Even if you expect adding more flags, u128 would double your capacity,
> > and people will still be able to use language-supported operation on
> > the bits in flag. Which looks simpler to me...
>
> u128 isn't supported on all architectures, VMA flags have to have absolutely
What about big integers?
typedef unsigned _BitInt(VMA_FLAGS_COUNT) vma_flags_t
> We want to be able to arbitrarily extend this as we please in the future. So
> using u64 wouldn't buy us _anything_ except getting the 32-bit kernels in
> line.
So enabling 32-bit arches is a big deal, even if it's a temporary
solution. Again, how many flags in your opinion are blocked because of
32-bit integer limitation? How soon 64-bit capacity will get fully
used?
> Using an integral value doesn't give us any kind of type safety, nor does it
> give us as easy a means to track what users are doing with flags - both
> additional benefits of this change.
I tried the below, and it works OK for me with i386:
$ cat bi.c
#include <stdio.h>
#include <limits.h>
int main() {
unsigned _BitInt(128) a = (_BitInt(128))1 << 65;
unsigned _BitInt(128) b = (_BitInt(128))1 << 66;
printf("a | b == %llx\n", (unsigned long long)((a | b)>>64));
printf("BITINT_MAXWIDTH == 0x%x\n", BITINT_MAXWIDTH);
return 0;
}
$ clang -m32 -std=c2x bi.c
$ ./a.out
a | b == 6
BITINT_MAXWIDTH == 0x800000
I didn't make GCC building it, at least out of the box. So the above
question about 64-bit capacity has a practical meaning. If we've got a
few years to let GCC fully support big integers as clang does, we don't
have to wish anything else.
I'd like to put it right. I maintain bitmaps, and I like it widely
adopted. But when it comes to flags, being able to use plain logic
operations looks so important to me so I'd like to make sure that
switching to bitmaps is the only working option.
