> This clearly is insecure coding.
Yes, it was intended to be an example of what gcc does with bad code.
> When such assumptions are made ... the compiler may eliminate the bug
> in some cases giving the programmer a false feeling that "Oh! My code
> is bug free". The problem is that when the code is compiled on a
> different platform, with different switches, the bug may reappear.
Yes. I was not intending to advocate reliance on the optimisation. I
was attempting to illustrate that things are not as simple as Cert is
claiming.
> I
> just wanted to bring out the point about the assumption ... may be a
> diagnostic should be issued.
I believe this is being done as we talk.
Ralph.
Or the compiler is smart enough to figure
> out the values of "buf" and only optimise on cases which are safe.
>
> >
> > Compiled on i386, gcc-4.3.0 with -O2 gives:
> >
> > foo:
> > xorl %eax, %eax
> > cmpl $99, 8(%esp)
> > setle %al
> > ret
> >
> > E.g., calling foo with:
> >
> > #include <stdio.h>
> > int main()
> > {
> > char buf[100];
> > printf ("%d\n", foo (buf, 1500000000));
> > return 0;
> > }
> >
> > on my PC (where the stack is just below the 3Gig position).
> >
> >
> >
> > > > Why is Cert advising people to avoid an optimisation that can
> > > > --- realistically, although probably rarely --- remove security
> > > > vulnerabilities?
> > > >
> > > If you are referring to VU#694123, this refers to an optimization
> >
> > I'm talking about 162289.
> >
> > Ralph.
> >
> >
> >
> > > that removes checks pointer arithmetic wrapping. The
> > > optimization doesn't actually eliminate the wrapping behavior;
> > > this still occurs. It does, however, eliminate certain kinds of
> > > checks (that depend upon undefined behavior).
> > >
> > > Thanks,
> > > rCs
> >
