fork() can fail

Re:fork() can fail by dllthomas on Wednesday August 20, 2014 @05:29PM (#8204763)

A null pointer does not need to have an all-zero representation, which mattered once on some architectures. I'm not aware of any current architecture that does it that way, but that's still what the standard says, which is to say that C does technically have a notion of null which is not necessarily identical with 0.

http://c-faq.com/null/machexamp.html

[ Parent | on HN ]

Re:fork() can fail by spc476 on Wednesday August 20, 2014 @05:38PM (#8204805)

But in C, a 0 in a pointer context is always considered the NULL pointer (even if the physical value of a NULL pointer isn't all zeros).

[ Parent | on HN ]

Re:fork() can fail by cperciva on Wednesday August 20, 2014 @06:14PM (#8204972)

Only a compile-time constant zero. So

    assert(NULL == (void *)0);

is fine, but

    int x = 0;
    assert(NULL == (void *)x);

is not.

[ Parent | on HN ]

Re:fork() can fail by loup-vaillant on Wednesday August 20, 2014 @06:13PM (#8204966)

Additionally in a boolean context a null pointer is indistinguishable from "false" (meaning, zero).

http://c-faq.com/null/ptrtest.html

For practical purposes, the null pointer and the integer `0` are one and same.

[ Parent | on HN ]

Re:fork() can fail by dllthomas on Wednesday August 20, 2014 @07:34PM (#8205236)

"For practical purposes, the null pointer and the integer `0` are one and same."

For most practical purposes, which is why I said that it wasn't a terrible approximation. However, they can be distinguished on some architectures:

    intptr_t x = 0;
    void *p = 0;
    
    x == *(intptr_t*)(char*)&p;

I can easily construct fantasy scenarios (involving more than a bit of Doing It Wrong) where this would be relevant. I'm not convinced it couldn't ever be relevant without Doing It Wrong, if one in fact needed to work on that kind of a system.

[ Parent | on HN ]