From: Keith.S.Thompson+u@gmail.com   
      
   David Brown  writes:   
   > On 01/12/2025 17:56, Keith Thompson wrote:   
   >> David Brown  writes:   
   >> [...]   
   >>> (I am not entirely sure, but I think it is standards-conforming for an   
   >>> implementation to haev BITINT_MAXWIDTH set to 64 and support all   
   >>> _BitInts up size 64, and then also support _BitInts of multiples of 64   
   >>> thereafter.  Use of _BitInt greater than BITINT_MAXWIDTH is UB in the   
   >>> standard - so an implementation can choose to give that a defined   
   >>> behaviour for specific sizes.)   
   >> [...]   
   >> No, _BitInt(N) where N > BITINT_MAXWIDTH is a constraint violation.   
   >> N3220 6.7.3.1p2 ("Constraints") :   
   >>   
   >>      The parenthesized constant expression that follows the _BitInt   
   >>      keyword shall be an integer constant expression N that specifies   
   >>      the width (6.2.6.2) of the type. The value of N for unsigned   
   >>      _BitInt shall be greater than or equal to 1. The value of N   
   >>      for _BitInt shall be greater than or equal to 2.  The value of   
   >>      N shall be less than or equal to the value of BITINT_MAXWIDTH   
   >>      (see 5.2.5.3.2).   
   >>   
   >> As I mentioned before, there's a proposal for C2y to allow   
   >> signed _BitInt(1).   
   >>   
   >> Of course an implementation could do what you suggest as an   
   >> extension.   
   >   
   > Yes, of course - violating a constraint is UB, but it also requires a   
   > diagnostic.   
      
   I'd place a very different emphasis on that.  Violating a constraint   
   requires a diagnostic, which needn't necessarily be fatal.  If an   
   implementation chooses to accept the code anyway, the resulting   
   behavior is probably undefined (though the standard doesn't say   
   so explicitly).   
      
   >              So while an implementation could implement a limited   
   > selection of _BitInt's larger than BITINT_MAXWIDTH, if it is to   
   > conform to the C standards it would have to at least give a warning   
   > message when you used these _BitInt's.  As an extension (perhaps   
   > enabled by a flag), it could then suppress such diagnostics.   
      
   Suppressing mandatory diagnostics would not be an "extension" in   
   the way that term is defined by the standard.  It would simply be   
   a failure to conform to the standard.  Of course non-conforming   
   C-like compilers exist (like gcc in its default mode), and that's   
   not necessarily a bad thing.   
      
   But given that several compilers have already implemented bit-precise   
   integer types *without* either allowing N > BITINT_MAXWDITH or   
   disallowing "odd" values, I don't think it will be an issue in   
   practice.   
      
   --   
   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)