[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Russell Shaw
Subject: Re: [avr-gcc-list] Re: WinAVR 20050214 (gcc 3.4.3) and optimizer bug.
Date: Mon, 09 May 2005 14:09:23 +1000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050105 Debian/1.7.5-1

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

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


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]