From: already5chosen@yahoo.com   
      
   On Sun, 23 Nov 2025 13:59:59 +0000   
   bart  wrote:   
      
   > On 23/11/2025 13:32, Waldek Hebisch wrote:   
   > > Philipp Klaus Krause  wrote:   
   > >> Am 22.10.25 um 14:45 schrieb Thiago Adams:   
   > >>>   
   > >>>   
   > >>> Is anyone using or planning to use this new C23 feature?   
   > >>> What could be the motivation?   
   > >>>   
   > >>>   
   > >>   
   > >> Saving memory by using the smallest multiple-of-8 N that will do.   
   > >   
   > > IIUC nothing in the standard says that it is smallest multiple-of-8.   
   > > Using gcc-15.1 on AMD-64 is get 'sizeof(_BitInt(22))' equal to 4,   
   > > while the number cound fit in 3 bytes.   
   >   
   > The rationale mentions a use-case where there is a custom processor   
   > that might actually have a 22-bit hardware types.   
   >   
   > Implementing such odd-size types on regular 8/16/32/64-bit hardware   
   > is full of problems if you want to do it without padding (in order to   
   > get the savings). On even with padding (to get the desired overflow   
   > semantics).   
   >   
   > Such as working out how pointers to them will work.   
   >   
   >   
   > >> Also   
   > >> being able to use bit-fields wider than int.   
   > >   
   > > For me main gain is reasonably standard syntax for integers bigger   
   > > that 64 bits.   
   >   
   > Standard syntax I guess would be something like int128_t and   
   > int256_t. Such wider integers tend to be powers of two.   
   >   
   > But there are two problems with _BitInt:   
   >   
   > * Any odd sizes are allowed, such as _BitInt(391)   
   >   
   > * There appears to be no upper limit on size, so _BitInt(2997901) is   
   > a valid type   
   >   
      
   Upper limit is implementation-defined.   
   On both existing implementations the limit (on 64-bit targets) appears   
   to be 2**16 or  2**16-1. I don't remember which one.   
      
      
   > So what is the result type of multiplying values of those two types?   
   >   
      
   I think, traditional C rules for integer types apply here as well: type   
   of result is the same as type of wider operand. It is arithmetically   
   unsatisfactory, but consistent with the rest of language.   
   And practically sufficient, because C programmers are already accustomed   
   to write statements like:   
   uint64_t foo(uint32_t x, uint16 y) { return (uint64_t)x*y; }   
      
   So it would be natural for them to write:   
   _BitInt(1536) foo(_BitInt(1024) x, _BitInt(512) y) {   
    return _BitInt(1536)x*y;   
   }   
      
   Since the pattern is so common already, optimizing compiler is likely to   
   understand the meaning and generate only necessary calculations.   
   Or, at least, to not generate too much of unnecessary calculations.   
      
   > Integer sizes greater than 1K or 2K bits should use an arbitrary   
   > precision type (which is how large _BitInts will likely be   
   > implemented anyway), where the precision is a runtime attribute.   
   >   
      
   I think, the Standard is written in such way that implementing _BitInt   
   as an arbitrary precision numbers, i.e. with number of bits held as part   
   of the data, is not allowed. Of course, Language Support Library can be   
   (and hopefully is, at least for gcc; clang is messy a.t.m.) based on   
   arbitrary precision core routines, but the API used by compiler should   
   be similar to GMP's mpn_xxx family of functions rather than GMP's   
   mpz_xxx family, i.e. # of bits as separate parameters from data arrays   
   rather than combined.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)