From: Keith.S.Thompson+u@gmail.com   
      
   bart  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.   
      
   I can see something this being done in C++ with operator   
   overloading.  See, for example, the std::vector partial   
   specialization.   
      
   [...]   
      
   > 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 */   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)