From: high.crew3868@fastmail.com   
      
   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.   
      
   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.   
      
      
   --   
   High Crew   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)