From: paul@lucasmail.org   
      
   On 1/5/26 6:39 AM, David Brown wrote:   
   > On 04/01/2026 12:51, highcrew wrote:   
   >> On 1/4/26 2:10 AM, Paul J. Lucas wrote:   
   >>> Perhaps a slightly better explanation of the same example:   
   >>>   
   >>> https://medium.com/@pauljlucas/undefined-behavior-in-c-and-c-   
   >>> f30844f20e2a   
   >   
   > That one starts off with a bit of a jumble of misconceptions.   
   >   
   >   
   > To start with, "undefined behaviour" does not exist because of   
   > compatibility issues or the merging of different C variations into one   
   > standard C.   
      
   ...   
      
   > The C standard is simply somewhat unusual in that it is more explicit   
   > about UB than many languages' documentation.  And being a language   
   > intended for maximally efficient code, C leaves a number of things as UB   
   > where other languages might throw an exception or have other error   
   > handling.   
      
   Other languages had the luxury of doing that.  As the article pointed   
   out, C had existed for over a decade before the standard and there were   
   many programs in the wild that relied on their existing behaviors.  By   
   this time, the C standard could not retroactively "throw an exception or   
   have other error handling" since it would have broken those programs, so   
   it _had_ to leave many things as UB explicitly.  Hence, the article   
   isn't wrong.   
      
   > Implementation defined behaviour is /not/ "bad" - pretty much all   
   > programs rely on implementation-defined behaviour such as the size of   
   > "int", character sets used, etc.  Relying on implementation-defined   
   > behaviour reduces the portability of code, but that is not necessary a   
   > bad thing.   
      
   It's "bad" if a naive programmer isn't aware it's implementation defined   
   and just assumes it's defined however it's defined on his machine.   
      
   > And while it is true that UB is "worse" than either implementation-   
   > defined behaviour or unspecified behaviour, it is not for either of the   
   > reasons given.  The *nix program "date" does not need to contain UB in   
   > order to produce different results at different times.   
      
   Sure, but the article didn't mean such cases. It meant for cases like   
   incrementing a signed integer past INT_MAX.  A program could   
   legitimately give different answers for the same line of code at   
   different times.   
      
   > It also makes the mistake common in discussions of UB optimisations of   
   > concluding that the optimisation makes the code "wrong".  Optimisations,   
   > such as the example of the "assign_not_null" function, are "logically   
   > valid" and /correct/ from the given source code.  Optimisations have not   
   > made the code "wrong", nor has the compiler.  The source code is correct   
   > for a given validity subset of its parameter types, and the object code   
   > is correct for that same subset.  If the source code is intended to work   
   > over a wider range of inputs, then it is the source code that is wrong -   
   > not the optimiser or the optimised code.   
   What the author meant is that optimization can make UB manifest more   
   bizarrely in ways than not optimizing wouldn't.  Code that contains UB   
   is always wrong.   
      
   - Paul   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)