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

Discussion in 'Mac Programming' started by kainjow, Feb 8, 2010.

  1. kainjow Moderator emeritus

    kainjow

    Joined:
    Jun 15, 2000
    #1
    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):

    Code:
    warning: the address of 'in' will always evaluate as 'true'
    The code is essentially:

    Code:
    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.
     
  2. Catfish_Man macrumors 68030

    Catfish_Man

    Joined:
    Sep 13, 2001
    Location:
    Portland, OR
    #2
    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.
     
  3. lee1210 macrumors 68040

    lee1210

    Joined:
    Jan 10, 2005
    Location:
    Dallas, TX
    #3
    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
     
  4. autorelease macrumors regular

    Joined:
    Oct 13, 2008
    Location:
    Achewood, CA
    #4
    "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:
    Code:
    float *in = new float[SIZE];
    Then it would make sense to check in against NULL.
     
  5. kainjow thread starter Moderator emeritus

    kainjow

    Joined:
    Jun 15, 2000
    #5
    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.
     
  6. lee1210 macrumors 68040

    lee1210

    Joined:
    Jan 10, 2005
    Location:
    Dallas, TX
    #6
    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
     
  7. lloyddean macrumors 6502a

    Joined:
    May 10, 2009
    Location:
    Des Moines, WA
    #7
    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.
     
  8. kainjow thread starter Moderator emeritus

    kainjow

    Joined:
    Jun 15, 2000
    #8
    yea, that makes more sense.
     
  9. jared_kipe macrumors 68030

    jared_kipe

    Joined:
    Dec 8, 2003
    Location:
    Seattle
    #9
    Dereferencing a null pointer should segfault, right?
     
  10. lloyddean macrumors 6502a

    Joined:
    May 10, 2009
    Location:
    Des Moines, WA
  11. kainjow thread starter Moderator emeritus

    kainjow

    Joined:
    Jun 15, 2000
    #11
    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 :)
     
  12. chown33 macrumors 604

    Joined:
    Aug 9, 2009
    #12
    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.
     

Share This Page