NULL: Is it guaranteed to evaluate 'not true'

Discussion in 'C Programming' started by Mark A. Odell, Sep 25, 2003.

  1. Is NULL guaranteed to evaluate 'not true', e.g. is it completely safe and
    portable to write:

    char *pFoo = malloc(1024);
    if (pFoo)
    {
    /* use pFoo
    */
    free(pFoo);
    }

    Or must I check against NULL explicitly as in:

    if (pFoo != NULL) ...

    Thanks.

    --
    - Mark ->
    --
     
    Mark A. Odell, Sep 25, 2003
    #1
    1. Advertising

  2. Mark A. Odell <> scribbled the following:
    > Is NULL guaranteed to evaluate 'not true', e.g. is it completely safe and
    > portable to write:


    > char *pFoo = malloc(1024);
    > if (pFoo)
    > {
    > /* use pFoo
    > */
    > free(pFoo);
    > }


    AFAIK it's indeed guaranteed to evaluate as "not true". Some C expert
    will probably offer a more qualified opinion here.

    --
    /-- Joona Palaste () ---------------------------\
    | Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
    | http://www.helsinki.fi/~palaste W++ B OP+ |
    \----------------------------------------- Finland rules! ------------/
    "This isn't right. This isn't even wrong."
    - Wolfgang Pauli
     
    Joona I Palaste, Sep 25, 2003
    #2
    1. Advertising

  3. Mark A. Odell

    Mike Wahler Guest

    Re: Is it guaranteed to evaluate 'not true'

    "Mark A. Odell" <> wrote in message
    news:Xns94018E49B3212CopyrightMarkOdell@130.133.1.4...
    > Is NULL guaranteed to evaluate 'not true',


    Yes.

    > e.g. is it completely safe and
    > portable to write:
    >
    > char *pFoo = malloc(1024);


    Portable, but not safe, since you didn't check
    if malloc() succeeded or failed. If it failed,
    then a dereference of 'pFoo' will give undefined
    behavior.

    > if (pFoo)


    This will be true if 'pFoo' is not == NULL.

    > {
    > /* use pFoo
    > */
    > free(pFoo);
    > }
    >
    > Or must I check against NULL explicitly as in:
    >
    > if (pFoo != NULL) ...


    No, you don't have to, but many coders prefer to
    explicitly compare against NULL in the interest
    of clarity.

    -Mike
     
    Mike Wahler, Sep 25, 2003
    #3
  4. Re: Is it guaranteed to evaluate 'not true'

    "Mike Wahler" <> wrote in
    news:vbGcb.3403$:

    >> NULL: Is it guaranteed to evaluate 'not true'

    >
    > Yes.
    >
    >> e.g. is it completely safe and
    >> portable to write:
    >>
    >> char *pFoo = malloc(1024);

    >
    > Portable, but not safe, since you didn't check
    > if malloc() succeeded or failed.


    I didn't? What's the following if (pFoo) for then? I did not dereference
    pFoo until after the check if (pFoo).

    > If it failed,
    > then a dereference of 'pFoo' will give undefined
    > behavior.
    >
    >> if (pFoo)

    >
    > This will be true if 'pFoo' is not == NULL.
    >
    >> {
    >> /* use pFoo
    >> */
    >> free(pFoo);
    >> }
    >>
    >> Or must I check against NULL explicitly as in:
    >>
    >> if (pFoo != NULL) ...

    >
    > No, you don't have to, but many coders prefer to
    > explicitly compare against NULL in the interest
    > of clarity.


    I am certainly not one of them. I prefer C's "boolean" comparisons to
    explicit values. Thanks for the reply.

    --
    - Mark ->
    --
     
    Mark A. Odell, Sep 25, 2003
    #4
  5. Mark A. Odell

    Mike Wahler Guest

    Re: Is it guaranteed to evaluate 'not true'

    "Mark A. Odell" <> wrote in message
    news:Xns9401911CD38EDCopyrightMarkOdell@130.133.1.4...
    > "Mike Wahler" <> wrote in
    > news:vbGcb.3403$:
    >
    > >> NULL: Is it guaranteed to evaluate 'not true'

    > >
    > > Yes.
    > >
    > >> e.g. is it completely safe and
    > >> portable to write:
    > >>
    > >> char *pFoo = malloc(1024);

    > >
    > > Portable, but not safe, since you didn't check
    > > if malloc() succeeded or failed.

    >
    > I didn't? What's the following if (pFoo) for then? I did not dereference
    > pFoo until after the check if (pFoo).


    I'm still asleep it seems. :)

    > > If it failed,
    > > then a dereference of 'pFoo' will give undefined
    > > behavior.
    > >
    > >> if (pFoo)

    > >
    > > This will be true if 'pFoo' is not == NULL.
    > >
    > >> {
    > >> /* use pFoo
    > >> */
    > >> free(pFoo);
    > >> }
    > >>
    > >> Or must I check against NULL explicitly as in:
    > >>
    > >> if (pFoo != NULL) ...

    > >
    > > No, you don't have to, but many coders prefer to
    > > explicitly compare against NULL in the interest
    > > of clarity.

    >
    > I am certainly not one of them.


    Nor am I, except when constrained by coding standards
    that require it.

    <I prefer C's "boolean" comparisons to
    > explicit values.


    As do I.

    > Thanks for the reply.


    Thanks for the wake-up. :)

    -Mike
     
    Mike Wahler, Sep 25, 2003
    #5
  6. Mark A. Odell

    Nick Austin Guest

    On 25 Sep 2003 17:59:15 GMT, "Mark A. Odell" <>
    wrote:

    >Is NULL guaranteed to evaluate 'not true', e.g. is it completely safe and
    >portable to write:
    >
    >char *pFoo = malloc(1024);
    >if (pFoo)
    >{
    > /* use pFoo
    > */
    > free(pFoo);
    >}


    Correct and entirely safe.

    if() expects an integer expression, which conventionally would be
    the result yielded by a relational operator such as !=. This
    result will either by zero (false) or non-zero (true).

    If if() is supplied with a pointer expression this causes an
    implicit pointer-to-integer conversion. In this case a
    non-NULL pointer is converted to a non-zero integer. The NULL
    pointer is converted to zero.

    Nick.
     
    Nick Austin, Sep 25, 2003
    #6
  7. On Thu, 25 Sep 2003, Nick Austin wrote:
    >
    > On 25 Sep 2003 17:59:15 GMT, "Mark A. Odell" wrote:
    > >
    > >Is NULL guaranteed to evaluate 'not true', e.g. is it completely safe and
    > >portable to write:
    > >
    > >char *pFoo = malloc(1024);
    > >if (pFoo)

    >
    > Correct and entirely safe.
    >
    > if() expects an integer expression,


    Not true. 'if' expects to be controlled by an expression of
    *scalar* type (basically, anything except an aggregate).

    > which conventionally would be
    > the result yielded by a relational operator such as !=. This
    > result will either by zero (false) or non-zero (true).


    Sort of. 'if' compares its controlling expression to 0. If
    it's not equal to 0, the body of the 'if' is executed. Otherwise,
    the body of the 'if' is *not* executed. That's all.

    For example,

    if (foo)

    is exactly equivalent to

    if ((foo) != 0)

    [you see now why aggregate types are not permitted in 'if'
    conditions]. So, specifically,

    if (pFoo)
    if ((pFoo) != 0)

    are equivalent expressions. And since 0 is in a pointer
    context here, it's equivalent to a null pointer of type 'char *';
    that is,

    if (pFoo)
    if ((pFoo) != NULL)
    if ((pFoo) != (char*)0)

    are also all equivalent. And of course they all do what you'd
    expect.


    > If if() is supplied with a pointer expression this causes an
    > implicit pointer-to-integer conversion.


    Nonsense. There is no "implicit pointer-to-integer conversion."
    Ever. Under any circumstances. The language specifically
    forbids it. The only implicit conversions are from pointers
    to other pointer types, or from arrays to pointers, or between
    different arithmetic types. That's it. (Unless I missed one.)

    -Arthur
     
    Arthur J. O'Dwyer, Sep 25, 2003
    #7
  8. Mark A. Odell

    Mike Wahler Guest

    "Nick Austin" <> wrote in message
    news:...

    > if() expects an integer expression, which conventionally would be
    > the result yielded by a relational operator such as !=. This
    > result will either by zero (false) or non-zero (true).
    >
    > If if() is supplied with a pointer expression this causes an
    > implicit pointer-to-integer conversion.


    This is news to me. Chapter and verse?

    -Mike
     
    Mike Wahler, Sep 25, 2003
    #8
  9. Mark A. Odell

    Micah Cowan Guest

    "Mike Wahler" <> writes:

    > "Nick Austin" <> wrote in message
    > news:...
    >
    > > if() expects an integer expression, which conventionally would be
    > > the result yielded by a relational operator such as !=. This
    > > result will either by zero (false) or non-zero (true).
    > >
    > > If if() is supplied with a pointer expression this causes an
    > > implicit pointer-to-integer conversion.

    >
    > This is news to me. Chapter and verse?


    (To me too...)

    Actually, the "implied conversion" would be integer-to-pointer,
    since (according to the standard's definition), the scalar
    expression will be compared with 0, requiring 0 to be converted
    to NULL first.

    (Naturally, by the as-if clause, no actual conversion is likely
    in practice...)

    -Micah
     
    Micah Cowan, Sep 25, 2003
    #9
  10. "Mark A. Odell" <> wrote in message news:<Xns94018E49B3212CopyrightMarkOdell@130.133.1.4>...
    > Is NULL guaranteed to evaluate 'not true',


    Yes. The 'truth' of an arbitrary expressions X is determined by whether
    "the expression compares unequal to 0." i.e. (X != 0).

    > e.g. is it completely safe and
    > portable to write:
    >
    > char *pFoo = malloc(1024);
    > if (pFoo)
    > {
    > /* use pFoo
    > */
    > free(pFoo);
    > }


    Yes.

    >
    > Or must I check against NULL explicitly as in:
    >
    > if (pFoo != NULL) ...


    No.

    --
    Peter
     
    Peter Nilsson, Sep 26, 2003
    #10
  11. Mark A. Odell

    pete Guest

    Arthur J. O'Dwyer wrote:

    > The only implicit conversions are from pointers
    > to other pointer types, or from arrays to pointers, or between
    > different arithmetic types.


    Conversions from pointers to other pointer types require casts,
    unless the conversion is to or from type pointer to void.

    --
    pete
     
    pete, Sep 26, 2003
    #11
  12. Mark A. Odell

    dis Guest

    Re: Is it guaranteed to evaluate 'not true'

    "Mark A. Odell" <> wrote in message
    news:Xns94018E49B3212CopyrightMarkOdell@130.133.1.4...

    > Is NULL guaranteed to evaluate 'not true', e.g. is it completely safe and
    > portable to write:
    >
    > char *pFoo = malloc(1024);
    > if (pFoo)
    > {
    > /* use pFoo
    > */
    > free(pFoo);
    > }
    >
    > Or must I check against NULL explicitly as in:
    >
    > if (pFoo != NULL) ...


    Both code fragments above are compliant. Note however that the argument to
    the assert macro must be of type int under the C90 standard (and must be of
    scalar type under the C99 standard):

    #include <assert.h>
    int main(void)
    {
    char *p = 0;
    assert(p != 0); /* compliant under C90 and C99 */
    assert(p); /* compliant under C99 only */
    return 0;
    }
     
    dis, Sep 26, 2003
    #12
  13. Re: Is it guaranteed to evaluate 'not true'

    "dis" <> wrote in
    news:bl0ape$pes$1.nb.home.nl:

    > Note however that the argument to
    > the assert macro must be of type int under the C90 standard (and must be
    > of scalar type under the C99 standard):
    >
    > #include <assert.h>
    > int main(void)
    > {
    > char *p = 0;
    > assert(p != 0); /* compliant under C90 and C99 */
    > assert(p); /* compliant under C99 only */
    > return 0;
    > }


    This is a good point to make. Thank you. I hope that C99 compliant
    compilers will soon dominate the C compiler market. However, Microsoft
    seems not to be too interested judging by some previous posts.

    --
    - Mark ->
    --
     
    Mark A. Odell, Sep 26, 2003
    #13
  14. Mark A. Odell

    Dan Pop Guest

    In <Xns94018E49B3212CopyrightMarkOdell@130.133.1.4> "Mark A. Odell" <> writes:

    >Is NULL guaranteed to evaluate 'not true', e.g. is it completely safe and
    >portable to write:
    >
    >char *pFoo = malloc(1024);
    >if (pFoo)
    >{
    > /* use pFoo
    > */
    > free(pFoo);
    >}
    >
    >Or must I check against NULL explicitly as in:
    >
    >if (pFoo != NULL) ...


    Ever considered reading the FAQ?

    5.3: Is the abbreviated pointer comparison "if(p)" to test for non-
    null pointers valid?

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Sep 26, 2003
    #14
  15. (Dan Pop) wrote in news:bl1iai$emi$:

    [snip]

    >>if (pFoo != NULL) ...

    >
    > Ever considered reading the FAQ?


    Yes, I've done so on many occasion. I seem unable to retain the entire
    body of knowledge it contains yet still believe to remember it in toto.
    You're a bit late to the party on this one, you need to check news more
    often.

    --
    - Mark ->
    --
     
    Mark A. Odell, Sep 26, 2003
    #15
  16. On Fri, 26 Sep 2003 00:55:27 GMT, pete <> wrote:

    > Arthur J. O'Dwyer wrote:
    >
    > > The only implicit conversions are from pointers
    > > to other pointer types, or from arrays to pointers, or between
    > > different arithmetic types.

    >

    And from function (designator) to pointer, and non-array lvalue to
    (r)value, although the latter especially rather stretches the meaning
    of the word. And in C99 pointer to _Bool, just for the heck of it.

    > Conversions from pointers to other pointer types require casts,
    > unless the conversion is to or from type pointer to void.


    Or to add qualification.

    - David.Thompson1 at worldnet.att.net
     
    Dave Thompson, Sep 29, 2003
    #16
  17. Mark A. Odell

    pete Guest

    Dave Thompson wrote:
    >
    > On Fri, 26 Sep 2003 00:55:27 GMT, pete <> wrote:
    >
    > > Arthur J. O'Dwyer wrote:
    > >
    > > > The only implicit conversions are from pointers
    > > > to other pointer types, or from arrays to pointers, or between
    > > > different arithmetic types.

    > >

    > And from function (designator) to pointer, and non-array lvalue to
    > (r)value, although the latter especially rather stretches the meaning
    > of the word. And in C99 pointer to _Bool, just for the heck of it.
    >
    > > Conversions from pointers to other pointer types require casts,
    > > unless the conversion is to or from type pointer to void.

    >
    > Or to add qualification.


    Thank you.

    --
    pete
     
    pete, Sep 29, 2003
    #17
  18. Mark A. Odell

    Dan Pop Guest

    In <Xns940285F4FDD1DCopyrightMarkOdell@130.133.1.4> "Mark A. Odell" <> writes:

    > (Dan Pop) wrote in news:bl1iai$emi$:
    >
    >[snip]
    >
    >>>if (pFoo != NULL) ...

    >>
    >> Ever considered reading the FAQ?

    >
    >Yes, I've done so on many occasion. I seem unable to retain the entire
    >body of knowledge it contains yet still believe to remember it in toto.


    Does this somehow mean that Mark A. Odell is exempt from the usual
    requirement of checking the FAQ before asking questions?

    >You're a bit late to the party on this one, you need to check news more
    >often.


    You're in dire need of a clue about how Usenet works!

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Sep 29, 2003
    #18
  19. (Dan Pop) wrote in news:bl9fij$368$:

    >>[snip]
    >>
    >>>>if (pFoo != NULL) ...
    >>>
    >>> Ever considered reading the FAQ?

    >>
    >>Yes, I've done so on many occasion. I seem unable to retain the entire
    >>body of knowledge it contains yet still believe to remember it in toto.

    >
    > Does this somehow mean that Mark A. Odell is exempt from the usual
    > requirement of checking the FAQ before asking questions?


    No, of course not. But I'm sure you know that I have read the FAQ despite
    your implication, "Ever" to mean I have never read the FAQ.

    >>You're a bit late to the party on this one, you need to check news more
    >>often.

    >
    > You're in dire need of a clue about how Usenet works!


    So you're telling me that your feed, typically quite responsive wasn't as
    of late? I can except that Dan and yes I do know that usenet is not
    immediate and has no such guarantee and that newservers may or may not
    propagate messages in a time-regular manner.

    --
    - Mark ->
    --
     
    Mark A. Odell, Sep 29, 2003
    #19
  20. Mark A. Odell

    Dan Pop Guest

    In <Xns94056FCAC859FCopyrightMarkOdell@130.133.1.4> "Mark A. Odell" <> writes:

    > (Dan Pop) wrote in news:bl9fij$368$:
    >
    >>>[snip]
    >>>
    >>>>>if (pFoo != NULL) ...
    >>>>
    >>>> Ever considered reading the FAQ?
    >>>
    >>>Yes, I've done so on many occasion. I seem unable to retain the entire
    >>>body of knowledge it contains yet still believe to remember it in toto.

    >>
    >> Does this somehow mean that Mark A. Odell is exempt from the usual
    >> requirement of checking the FAQ before asking questions?

    >
    >No, of course not. But I'm sure you know that I have read the FAQ despite
    >your implication, "Ever" to mean I have never read the FAQ.


    OK, so you're sarcasm impaired. Unfortunately, there is no universally
    accepted emoticon for sarcasm.

    >>>You're a bit late to the party on this one, you need to check news more
    >>>often.

    >>
    >> You're in dire need of a clue about how Usenet works!

    >
    >So you're telling me that your feed, typically quite responsive wasn't as
    >of late?


    I'm telling you that it is downright foolish to make *any* assumptions
    about someone's news feed. There are far too many things that can
    happen at any type, regardless of its usual quality.

    According to the c.l.c image provided my news server, no one else
    had pointed you to the FAQ at the time I did it. Not being omniscient,
    I had no idea about the contents of the posts that were still traveling
    across the wire.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Sep 30, 2003
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. darrel
    Replies:
    8
    Views:
    441
    Michael Ramey
    Feb 11, 2004
  2. Replies:
    5
    Views:
    26,702
    Mike Schilling
    Mar 29, 2006
  3. Paminu

    Which numbers evaluate to true and false?

    Paminu, Oct 4, 2005, in forum: C Programming
    Replies:
    22
    Views:
    830
    August Karlstrom
    Oct 6, 2005
  4. bdb112
    Replies:
    45
    Views:
    1,348
    jazbees
    Apr 29, 2009
  5. Steve
    Replies:
    5
    Views:
    179
Loading...

Share This Page