Mark Mitchell wrote on :

> Mark Mitchell wrote:
> 
>> I've been told that Intel's ICC compiler also does this optimization:
> 
> Apparently, IAR's Atmel AVR compiler does this optimization as well.


  Say, how do I get gcc to actually do this?  I can't reproduce this in a
real-world test.  I would have thought that the call to bar should be
optimised away in the example below, but it doesn't seem to be (tested on a
cygwin host with a recent gcc built from trunk rev.133266):


~ $ gcc -O3 -S -xc -o 2.s -
extern void foo (char *buf, int len);
extern void bar (char *buf);

void foo (char *buf, int len)
{
  if (buf+len < buf)
  {
    bar (buf);
  }
  return;
}

void delay (int time)
{
  int i;
  for (i = 0; i < time; i++) ;
}

~ $ cat 2.s
        .file   ""
        .text
        .p2align 4,,15
.globl _delay
        .def    _delay; .scl    2;      .type   32;     .endef
_delay:
        pushl   %ebp
        movl    %esp, %ebp
        popl    %ebp
        ret
        .p2align 4,,15
.globl _foo
        .def    _foo;   .scl    2;      .type   32;     .endef
_foo:
        pushl   %ebp
        movl    %esp, %ebp
        movl    12(%ebp), %eax
        testl   %eax, %eax
        js      L7
        popl    %ebp
        ret
        .p2align 4,,7
L7:
        popl    %ebp
        jmp     _bar
        .def    _bar;   .scl    2;      .type   32;     .endef
~ $ gcc --version
gcc (GCC) 4.4.0 20080316 (experimental)
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

~ $


  It looks to me like it got changed into a test if len is negative, which is
right, isn't it?

  Does this optimisation perhaps *only* happen in artificial testcases like
the one at the start of the thread, where 'len' is a compile-time constant
that gcc *knows* is positive?  Because if so, surely the CERT alert is
more-or-less spurious, rather than
perhaps-at-least-a-bit-useful-to-people-who-write-invalid-code?

  BTW, as you might also notice in that example, Gcc now optimises away empty
'delay' loops.  Unlike the impossible-range-check optimisation, this really is
new behaviour, at least since 3.x series.  Theoretically, this too could have
security implications for incorrect code.  Maybe there should be another
warning issued?


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Reply via email to