Re: Joy of this, Joy of that

186282@ud0s4.net <186283@ud0s4.net> wrote:

On 11/25/24 4:07 AM, Richard Kettlewell wrote:

"186282@ud0s4.net" <186283@ud0s4.net> writes:

   Note though ... almost NO compu-geeks these days
   know ASM. As such they will not be enlightened
   about 'C' in that fashion. Today's geeks mostly
   start with Python and MIGHT go a little further,
   likely Rust.
>
   Just sayin'
>
   Things changed between 1984 and 2024.
>
   We Old Guys can kinda look at 'C' and see
   the ASM it's going to become. Later gens
   do not.

 
It’s a common mental model for C, but it’s not accurate.  The language
spec leaves an awful lot of wiggle room for the generated code to
diverge from the “I can see the assembler” model and compilers take full
advantage of it.
 
A simple example, based on a historical Linux kernel vulnerability
(CVE-2009-1897):
 
     int f(int *xp) {
         int x = *xp;
         if(!xp)
           return 0;
         return x;
     }
 
In the “assembler” model it would compile to something like this:
 
        mov eax,dword ptr [rdi]
        cmp rdi,0
        jne L1
        mov eax,0
     L1:
        ret
 
In fact at -O2 the test on xp is optimized out:
 
        mov eax, dword ptr [rdi]
        ret
 
https://godbolt.org/z/caKeTMTxf to play further.
 

  ...
  That final example shows how tight that particular bit CAN be made. 
  How the compiler figures that out - NO idea !

Did you miss the forest for the trees.  The final example is incorrect
based upon the plain meaning (albeit incorrect) of the input C source.

The check for a null "xp" value that is present in the C code has
disappeared in the output Assembly.  The f() function has become
f(int *xp) { return *xp; }.  Zero will only return from it when what xp
points at contains zero.

Granted, the C code is also wrong, in that "xp" is dereferenced before
it is checked to see if is null.

How the compiler 'figure[ed] that out' is that the C standard says
dereferencing a null pointer is undefined.  So the compiler writers
decided that if the author wrote the dereference, they were also
asserting that "xp" would never be null at that point in their code. 
Therefore there was no need to check for "xp" being null on the next
line, as it can't be null there, because the programmer already said it
was not null by dereferencing it on the prior line (because the
programmer should know not to do that).  And the optimizer removed the
entire if statement as dead code that can never execute.