From: high.crew3868@fastmail.com   
      
   On 1/3/26 1:42 PM, David Brown wrote:   
   >> 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.   
      
   Simulations use that code. Then the same code is compiled for the target   
   platform.   
      
   On the light of what I learned on this thread, the value of such testing   
   is not just mere "let's see if it crashes", but effectively bound to UB!   
   Or to the attempt to rule out the existing of UB, I should rather say.   
      
   Sanitizer to the rescue. Assuming UB is not in the code, we saddle the   
   (cross)compiler of the correctness of the output.   
      
   Then - I'm reasoning as I write - the devil is in the details.   
   Let's say that the compiler is unable to catch the issues, and so are   
   the sanitizers. Then the UB-tainted source code goes to the target.   
   Assuming the cross compiler is unable to catch it either, we have   
   a garbage-in-garbage-out situation, affecting the product.   
      
   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?).   
      
      $ cat x.c   
      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++) {   
              if (table[i] == v) return 1;   
          }   
          return 0;   
      }   
      $ gcc -c -O2 x.c   
      $ objdump --disassemble=exists_in_table x.o   
      
      x.o:     file format elf64-x86-64   
      
      
      Disassembly of section .text:   
      
      0000000000000000 :   
         0:   b8 01 00 00 00          mov    $0x1,%eax   
         5:   c3                      ret   
      
   OK, this is the bad guy. ...now let's sanitize it.   
      
      $ gcc -c -fsanitize=address -O2 x.c   
      $ objdump --disassemble=exists_in_table x.o   
      
      x.o:     file format elf64-x86-64   
      
      
      Disassembly of section .text:   
      
      0000000000000000 :   
         0:   48 8d 05 00 00 00 00    lea    0x0(%rip),%rax        # 7   
      
         7:   48 8d 70 14             lea    0x14(%rax),%rsi   
         b:   48 89 c2                mov    %rax,%rdx   
         e:   48 c1 ea 03             shr    $0x3,%rdx   
        12:   0f b6 8a 00 80 ff 7f    movzbl 0x7fff8000(%rdx),%ecx   
        19:   48 89 c2                mov    %rax,%rdx   
        1c:   83 e2 07                and    $0x7,%edx   
        1f:   83 c2 03                add    $0x3,%edx   
        22:   38 ca                   cmp    %cl,%dl   
        24:   7c 04                   jl     2a    
        26:   84 c9                   test   %cl,%cl   
        28:   75 1c                   jne    46    
        2a:   39 38                   cmp    %edi,(%rax)   
        2c:   74 12                   je     40    
        2e:   48 83 c0 04             add    $0x4,%rax   
        32:   48 39 f0                cmp    %rsi,%rax   
        35:   75 d4                   jne    b    
        37:   31 c0                   xor    %eax,%eax   
        39:   c3                      ret   
        3a:   66 0f 1f 44 00 00       nopw   0x0(%rax,%rax,1)   
        40:   b8 01 00 00 00          mov    $0x1,%eax   
        45:   c3                      ret   
        46:   48 83 ec 08             sub    $0x8,%rsp   
        4a:   48 89 c7                mov    %rax,%rdi   
        4d:   e8 00 00 00 00          call   52 <__odr_asan.table+0x12>   
      
      Disassembly of section .text.exit:   
      
      Disassembly of section .text.startup:   
      
   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!   
      
   >> Thanks!   
   >>   
   >   
   > It's been a good thread - on-topic, interesting discussion, people have   
   > got a better understanding of a few things, there's an opportunity to   
   > contribute to better C development tools, and no flames.  I look forward   
   > to your next question!   
      
   Thanks. I'm new here, and the community seems a good one! Happy to   
   contribute.   
      
   [Here I'm tempted to go OT with babbling about how nice it would be that   
   usenet wasn't so underground, but I suspect that is probably what makes   
   it good. In the small barrel, there is the good wine]   
      
   --   
   High Crew   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)