From: janis_papanagnou+ng@hotmail.com   
      
   On 2025-11-30 03:30:42, bart wrote:   
   > On 30/11/2025 00:46, Keith Thompson wrote:   
   >> bart  writes:   
   >>> You can have general _BitInt(N) syntax and have constraints on the   
   >>> values of N, not just an upper limit.   
   >>   
   >> No you can't, because the language does not allow the arbitrary   
   >> restrictions you want.  If an implementer finds _BitInt(1187)   
   >> too difficult, they can set BITINT_MAXWIDTH to 64.   
   >>   
   >> One more time: Both gcc and llvm/clang have already implemented   
   >> bit-precise types, with very large values of BITINT_MAXWIDTH.   
   >> What actual problems has this fact caused for you, other than giving   
   >> you something to complain about?   
   >   
   > What problem would there be if BitInt sizes above the machine word sizes   
   > had to be multiples of the word sizes?   
      
   Not sure whether you're talking at cross-purposes. (I haven't   
   followed all postings or details.)   
      
   If, on a 64-bit-word system, _BitInt(80) would produce an error   
   (because it "had to be multiples of the word sizes", as you say),   
   that would obviously be a problem, don't you think?   
      
   If all you want to express is that the underlying "transfer syntax"   
   (the memory to store those values) may cover a larger memory range,   
   one that may exceed the size [needed by the programmer] to the next   
   byte or word boundary, I wouldn't see a problem. (I'd actually even   
   expect that the [low-level] implementation range be something that's   
   supported by the system.)   
      
   (Care must in any case be taken in the definition of that feature   
   for memory accesses outside the defined bounds. - Don't know what   
   "C" defines here.)   
      
   >   
   > It what way would it inconvenience /you/?   
      
   If I couldn't define _BitInt(80) I'd indeed consider that a problem.   
   Or any other constant value that stems from my application domain.   
      
   >   
   > I just don't unlike unnecessarily flexible, lax or over-ambitious   
   > features in a language. I think that is as much poor design as   
   > underspecifying.   
      
   You mean you have problems with, say, "char a[81]" as well?   
      
   >   
   > So I'm interested in what that one extra bit in a million buys you. Or   
   > that one bit fewer.   
      
   It's not about extra bits. It's about making it possible to define   
   what your tasks (that are to be implemented) ask for. (In my book.   
   YMMV.)   
      
   What actual problems you have (or could imagine) with that?   
      
   Janis   
      
   >> [...]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)