From: Keith.S.Thompson+u@gmail.com   
      
   James Kuyper  writes:   
   > On 2025-12-01 15:42, Keith Thompson wrote:   
   >> David Brown  writes:   
   >>> On 01/12/2025 17:56, Keith Thompson wrote:   
   > ...   
   >>>> 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).   
   >   
   > Undefined behavior is indicated in only three ways:   
   > "If a "shall" or "shall not" requirement that appears outside of a   
   > constraint or runtime-constraint is violated, the behavior is undefined.   
   > Undefined behavior is otherwise indicated in this document by the words   
   > "undefined behavior" or by the omission of any explicit definition of   
   > behavior." (4p2).   
   >   
   > Which of those three methods do you think applies? This "shall" occurs   
   > inside a constraint. There's no explicit statement that it is undefined   
   > behavior. There is an explicit definition for the behavior, provided by   
   > what the standard says about _BitInt outside of this constraint.   
      
   It's not clear.   
      
   A constraint is defined as a "restriction, either syntactic   
   or semantic, by which the exposition of language elements is   
   interpreted".  I might argue that if a constraint is violated, it's   
   not possible to interpret the exposition of the language elements.   
   (That would fall under omission of any explicit definition of   
   the behavior.)   
      
   I'd like to see future edition of the standard explicitly state that   
   a constraint violation renders a program's behavior undefined.  Or an   
   explicit statement that it doesn't would still be an improvement.   
      
   --   
   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)