From: high.crew3868@fastmail.com   
      
   On 1/2/26 11:52 PM, Kaz Kylheku wrote:   
   > On 2026-01-01, highcrew  wrote:   
   > For the situation in your program, it would be unacceptable to have   
   > implementations stop translating.   
      
   I can somehow get the idea that it is difficult for the compiler   
   to spot the issue, but why do you think it would be unacceptable   
   to stop translating?   
      
   > We really want just a warning (at   
   > least by default; in specific project and situations, developers   
   > could elect to treat certain warnings as fatal, even standard-required   
   > warnings.)   
      
   Even a warning would be enough though.  Btw, my typical way of   
   working is to enable -Werror while developing, but I don't like   
   to force it in general.  That would be an interesting digression,   
   but definitely OT.   
      
   > The second new thing is that to diagnose this, we need to make   
   > diagnosis dependent on reachability.   
   >   
   > We want a rule which is something like "whenever the body of   
   > a function, or an initializing expression for an external definition   
   > reaches an expression which has unconditional undefined behavior   
   > that is not an unreachability assertion and not a documented   
   > extension, a warning diagnostic must be issued".   
      
   That's an interesting perspective: reachability.   
   Would you say that the incriminated piece of code is UB only if it   
   is reachable in the final program, therefore it is acceptable   
   to keep it as long as unreachable?   
      
   Now that I think of it, the __builtin_unreachable() implemented   
   by popular compilers is technically UB *if reached* :)   
      
   > This kind of diagnostic would be a good thing in my opinion; just   
   > nobody has stepped up to the plate because of the challenges:   
   >   
   > - introducing the concept of a warning versus error diagnostic.   
   >   
   > - defining a clear set of rules for trivial reachability which   
   >    can catch the majority of these situations without too much   
   >    complexity. (The C++ rules for functions that return value   
   >    reaching their end without a return statement can be used   
   >    as inspiration here.)   
   >   
   > - specifying exactly what "statically obvious" undefined behavior   
   >    is and how positively determine that a certain expression   
   >    exhibits it.   
   Now I'm wondering how much work it requires to properly define   
   the rules that the standard mandates!   
      
   As for me the main take-away is that the detection of certain UB   
   is non-trivial, it would be very evil if the standard was mandating   
   some nearly-impossible task to the compiler!   
      
      
    > (The C++ rules for functions that return value   
    >    reaching their end without a return statement can be used   
    >    as inspiration here.)   
      
   C++ does *what*?? I'm definitely not up to speed with C++, but   
   I totally have missed that.  Could you please tell me the name   
   of this bizarre feature? I *need* to look it up :D   
      
   --   
   High Crew   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)