From: david.brown@hesbynett.no   
      
   On 03/01/2026 14:42, highcrew wrote:   
   > On 1/3/26 1:42 PM, David Brown wrote:   
      
   [Be careful snipping attributions.  Make sure you have enough left for   
   all levels of quotation.  The following paragraph was written by you,   
   not by me.]   
      
   >>> Yes, I'm aware of this instruments, but I'm not very knowledgeable about   
   >>> it. I'd like to learn more, and I'll need to spend time doing so.   
   >>>   
   >>   
   >> The tools here can be useful.  Of course it is best when you can find   
   >> bugs earlier, at the static analysis stage (I am a big fan of lots of   
   >> compiler warnings), but the "-fsanatize" options are the next step for   
   >> a lot of development.  They are of limited value in my own work (small   
   >> embedded systems - there's often no console for log messages, and much   
   >> less possibility of "hardware accelerated" error detection such as   
   >> creative use of a processor's MMU), but for PC programming they can be   
   >> a great help.   
   >   
   > Agreed.   
   >   
   > I happen to work with embedded systems as well, and while I came late to   
   > the party (all the possible checks are already employed by colleagues   
   > who came before me. They took the fun part!), I can tell the value of   
   > sanitizers even if the code will later run on embedded systems.   
   > That's why I say I'd like to learn more: I'm merely a user of it.   
   >   
      
   >   
   > Following this thoughts, I started to wonder: the code I reported in   
   > the beginning of the thread, built with -O2, is effectively coping with   
   > UB by replacing the function with the equivalent of `return 1`.   
   > What if I build it with -O2 and -fsanitize=address?   
   > Will the instrumentation be able to catch it, given that there's nothing   
   > inherently bad around a `return 1` (minus the fact that it's not what   
   > the developer intended?).   
   >   
      
   >   
   > Well, what do you know? -fsanitize=address seems to interfere with   
   > optimizations, at least on my system. Link it, run it, and I get a nice   
   > segfault.   
   >   
   > Now the circle is closed!   
   >   
      
   The sanitizers effectively inject code into your source, before any   
   optimisations are applied.  You can imagine your code being transformed   
   into something like :   
      
      int table[4] = {0};   
      int exists_in_table(int v)   
      {   
          // return true in one of the first 4 iterations   
          // or UB due to out-of-bounds access   
          for (int i = 0; i <= 4; i++) {   
   // Start of sanitizer code   
              if (i < 0 || i > 3) halt_with_sanitizer_message();   
   // End of sanitizer code   
              if (table[i] == v) return 1;   
          }   
          return 0;   
      }   
      
   Then optimisations are applied as normal.   
      
   I can strongly recommend  as the tool of choice for   
   investigating code generation.  It only works well with small code   
   sections, but it gives you very clear generated code, and lets you try   
   it with hundreds of different compilers and compiler versions.  It's far   
   nicer than doing objdump's or using -Wa,ahsdl flags to generate listing.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)