From: tr.17687@z991.linuxsc.com   
      
   Keith Thompson  writes:   
      
   > 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.   
      
   I think a better description is "no behavior".  The C standard   
   specifies the meaning of C programs.  Source code that violates   
   one or more constraints is not a C program, even if it might look   
   like one.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)