Re: [avr-gcc-list] Re: WinAVR 20050214 (gcc 3.4.3) and optimizer bug.

[Russell Shaw]

E. Weddington wrote:
> Vesa Jääskeläinen wrote:
>
> > Joerg Wunsch wrote:
> >
> > > As Vesa Jääskeläinen wrote:
> > >
> > > > I have been debugging why Ethernut brakes in certain situations with
> > > > gcc. And found an optimizer bug.
> > In this clause:
> >         if (ppv && (*ppv != 0)) {
> >
> > We are missing code for (ppv != 0), but code for *ppv != 0 is found. And
> >  if I pass NULL to this function it makes compare to incorrect memory
> > location.
>
> Regardless of whether there is a compiler bug, the above is incorrect C. 
> You are NEVER supposed to rely on the fact that a NULL pointer is equal 
> to zero, because, technically, it can be defined as something else. You 
> should always directly compare a pointer to NULL as such:
>
> if(ppv != NULL && (*ppv != 0))

Only in cases where the context may not indicate where a pointer value is
required:

  http://www.eskimo.com/~scs/C-faq/q5.2.html
  http://www.eskimo.com/~scs/C-faq/q5.3.html
  http://www.eskimo.com/~scs/C-faq/s5.html

if (ppv && (*ppv != 0)) {  is ok.

Because of short-circuit boolean evaluation, (*ppv != 0) will not be
evaluated if ppv == 0. Note that some compilers may have an option
that disables short-circuit boolean evaluation.