From: david.brown@hesbynett.no   
      
   On 07/01/2026 03:08, Paul J. Lucas wrote:   
   > 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.   
   >   
      
   UB as a /concept/ does not exist because of compatibility issues.   
   Certain particular things may have been declared UB in C because of   
   compatibility between different existing compilers or different targets   
   (though it is more common for such things to be declared   
   "implementation-defined" rather than UB).  I am, however, having   
   difficulty finding examples of that for run-time UB.  (There are plenty   
   of situations where there is UB that could be identified at compile-time   
   or link time, but the standard does not require toolchains to diagnose.)   
      
   The idea that something can be expressed in a programming language,   
   without errors in syntax, but have no meaningful or correct behaviour,   
   is not new, and not restricted to C.  UB in C is not different from   
   asking for the square root of a negative number in the real domain, or   
   asking a kid to add 3 and 4 using the fingers of one hand.   
      
      
   >> 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.   
   >   
      
   Sure.  But that applies to all portability issues - people make all   
   sorts of assumptions about the system their code will be used on, of   
   which the implementation-defined aspects of C are only a small part.   
      
   >> 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.   
      
   If the author meant something different, he/she should have written   
   something different.   
      
   > 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 could also give different answers for unspecified behaviour :   
      
   	int first(void) { printf("1 "); return 1; }   
   	int second(void) { printf("2 "); return 2; }   
      
   	int x = first() + second();   
      
   The evaluation order of the operands of the addition - and therefore the   
   order of the debug prints, is unspecified.  Not only is the order not   
   something specified by the C standards, but it is not something that   
   needs to be consistent even between different runs of the same code.   
      
   So this "giving different answers" is not something special about UB.   
      
   >   
   >> 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.   
   >   
      
   If the author meant something different from what he wrote, it would   
   have been better if he wrote what he meant.   
      
   Yes, in practice you /can/ get a wider variety of strange results from   
   code with UB if you use a highly optimising compiler compared to a   
   simple compiler.  But there are no guarantees there - you can get   
   strange results from UB when not optimising, and perhaps enabling   
   optimisation will give you simple and more consistent results (possibly   
   the results you expected, possibly not).   
      
   It is fine to tell people about some of the strange possibilities that   
   can occur when you have UB.  But anything that even sounds vaguely like   
   a suggestion that you can mitigate the dangers of UB by disabling   
   optimisation is bad.  Far too many C programmers believe that.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)