From: david.brown@hesbynett.no   
      
   On 02/01/2026 17:38, highcrew wrote:   
   > On 1/2/26 6:53 AM, Waldek Hebisch wrote:   
   >> highcrew  wrote:   
   >>   
   >> You do not get the formalism: compiler applies a lot transformations   
   >> which are supposed to be correct for programs obeying the C rules.   
   >> However, compiler does not understand the program.  It may notice   
   >> details that you missed, but it act essentialy blindly on   
   >> information it has.  And most transformations have only limited   
   >> info (storing all things that compiler infers would take a lot   
   >> of memory and searching all info would take a lot of time).   
   >>   
   >> Code that you see is a result of many transformations, possibly   
   >> hundreds or more.  The result is a conseqence of all steps,   
   >> but it could be hard to isolate a single "silly" step.   
   >> [...]   
   >   
   > Thanks for your answer.   
   >   
   > So you are basically saying that spotting such a problem is   
   > way more difficult than optimizing it? And indeed so difficult that the   
   > compiler fails at it?   
   >   
   >>> There's plenty of documentation, articles and presentations that   
   >>> explain how this can make very efficient code... but nothing   
   >>> will answer this question: do I really want to be efficiently   
   >>> wrong?   
   >>   
   >> By using C you implicitely gave "yes" as an answer.   
   >   
      
   When code contains UB, all guarantees are out the window.  There is no   
   "right" answer, so it doesn't really make sense to ask if you are   
   getting the wrong answer efficiently or inefficiently.  In effect,   
   because you are not giving the compiler valid correct C code, it can't   
   know what you really want - you can't reasonably complain about what you   
   get in response.  Compilers are not mind readers.   
      
   (Of course compilers try to go beyond the requirements of the C   
   language, to be helpful development aids rather than just "pure"   
   compilers.  And while good compilers /are/ helpful, there is always room   
   for improvement.)   
      
   > Wait, I don't think that makes sense.   
   > If we are talking about a legitimate limitation of the compilers, as you   
   > seem to suggest, then it is a different situation.   
   >   
   > Perhaps it would be more proper to say that, by using C, one implicitly   
   > accepts to take the burden of writing UB-free code.   
   > The compiler can't guarantee that it will detect UB, so the contract   
   > is: you get a correct program if you write correct code.   
   >   
      
   That's a good way to phrase it, IMHO.   
      
   The C language standards (together with any documented extensions,   
   modifications, or implementation-defined behaviour in the   
   implementation) provides a contract.  You, as the programmer, guarantee   
   to write correct source code.  In return, the compiler guarantees to   
   generate correct object code.  If you fail on your part, and write UB in   
   your code, the compiler is under no obligation to give you anything   
   useful in return.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)