macOS Question about "the address will always evaluate as true" warning

[kainjow]

I recently got put on a new project that uses C++ at its core and came across this warning when using the 10.6 SDK (GCC 4.2):

warning: the address of 'in' will always evaluate as 'true'

The code is essentially:

float *in[SIZE];
if (in)
    memcpy(in, src, src_size);
else
{
    for (int i=0; i<len; i++)
        in[i] = dummyValue;
}

I don't get the warning with the 10.4 SDK. According to the header this code is at least 7 years old. Was there some type of chance that the pointer could be NULL with an older compiler? I'm confused as to why this was written like so, and why even if it was NULL, they would still try to access it. Note that this code is inside a C++ method.

 

[Catfish_Man]

That's really weird. I suggest you figure out exactly what it's intending to do, then kill it with fire so as to avoid confusion later on. Even if it's somehow technically not broken (which I doubt), it sure doesn't make sense.

 

[lee1210]

I don't believe in can ever be null. if it is, your stack is broken very badly. in will be the base of an array of SIZE float *s. If there isn't room on the stack to fit this array, your program should die before the code in this frame even starts.

But let's just say, for fun, that in was null. What the hell good is applying the array subscript operator [] to a null pointer? On the vast majority of systems, trying to assign something to address 0x0 (which the first iteration of the loop will do) is going to cause big problems.

In any event, i can't imagine this is what the code should do. I would actually suspect that the if should be if(src). In that case, if src is non-null it will copy src to in. It would be nice if src_size was compared to SIZE*sizeof(float*) first, though. Then in the else, if src is null, a dummy value is placed in every position in in. This at least seems like a sane thing to do.

-Lee

 

[autorelease]

"in" is being declared as an array of float pointers on the stack. Since it's being created on the stack, "in" can never be null and the if statement will always evaluate to true (nonzero).

Dang, Lee beat me to it! Anyway, it's pretty much bogus code. Maybe the author intended to use "new" or malloc() and allocate the array dynamically? Something like this:

float *in = new float[SIZE];

Then it would make sense to check in against NULL.

 

[kainjow]

My guess for why the if statement is there is maybe at one point "in" was created with c/malloc and so it could be NULL but at a later point they changed it over to just being on the stack and forgot to remove the if statement. Still, that doesn't explain the code in the else condition.

 

[lee1210]

I am pretty much convinced it should be if(src). in gets used in the if and the else, src is only in the if.

-Lee

 

[lloyddean]

The code is essentially:

float *in[SIZE];
if (in)
    memcpy(in, src, src_size);
else
{
    for (int i=0; i<len; i++)
        in[i] = dummyValue;
}

Given your use of the word "essentially" I believe you've reduced the code incorrectly as well.

If the code is indeed as shown the array of pointers to floats "in" will always evaluate to a non zero base address thus the if will always evaluate to true.

 

[kainjow]

I am pretty much convinced it should be if(src). in gets used in the if and the else, src is only in the if.

-Lee

yea, that makes more sense.

 

[jared_kipe]

Dereferencing a null pointer should segfault, right?

 

[lloyddean]

"exc_bad_access"

 

[kainjow]

Funny thing. I've been getting a EXC_BAD_ACCESS in this project and just now found that the memcpy was using sizeof(float) but should be sizeof(float*). On 32-bit the sizes are the same but on 64-bit they're not, which explains why it never crashed before. Ahh that is an old bug

 

[chown33]

Funny thing. I've been getting a EXC_BAD_ACCESS in this project and just now found that the memcpy was using sizeof(float) but should be sizeof(float*). On 32-bit the sizes are the same but on 64-bit they're not, which explains why it never crashed before. Ahh that is an old bug

Oh yes, those can be fun.

A long time ago, I started using sizeof(variable), or sizeof(*ptrVariable), so no matter what type the variable was, it would compile the right thing.