I'm finally putting aside my lurker roots with a predicament:

Here's the story: It was a quiz in one of my programming classes to add an element to the end of a linked list. Sounds simple enough. I get the quiz back, and I've lost two points because of a small error in traversing the list. It still sounds straightforward. However, the reason I lost points wasn't because the traversal was inherently flawed or anything. It was because of what I can only describe as semantics:


Code:
for(;temp->next;temp=temp->next); //only works if NULL==0


I was reasonably irked by the statement. After all, I'd written code like that and it has worked, so it might have been a fluke that only a compiler like gcc would forgive. Or maybe it was limited to a certain subset of compilers, because I've seen a similar line in the decompiled source code to Super Mario 64 (which was compiled on IDO 5.3).

I decided to look into it to see how exactly NULL and 0 are related, or whether they're related at all.

After consulting The C Programming Language (K&R C), I came across this passage:

"Pointers and integers are not interchangeable. Zero is the sole exception: the constant zero may be assigned to a pointer, and a pointer may be compared with the constant zero. The symbolic constant NULL is often used in place of zero, as a mnemonic to indicate more clearly that this is a special value for a pointer. NULL is defined in <stdio.h>. We will use NULL henceforth" (Kernighan & Ritchie, 1978)

What this passage seems to convey is that NULL is a constant put in place to not compare pointers to a magic number (0 in this case). So it would look something like:


Code:
#define NULL 0


To get another source to defend my claim, I consulted the ANSI standard for C89, just to make sure that the definition for NULL hadn't changed from the transition to standardization (after all, K&R C and ANSI C have quite a few differences).

What I found was that the ANSI C89 standard defines the NULL macro as one that "expands to an implementation-defined null pointer constant", where the null pointer constant is defined as "An integral constant expression with the value 0, or such an expression cast to type void *". This further proves that NULL is used in place of 0 or at least (void*) 0.

With these sources gathered, I emailed the professor to get a second opinion on the issue. I got this in response:

"You are correct in that NULL is most always 0. However, the standard does not REQUIRE that it be 0."

What could they have meant by that? Do such evil compilers exist that don't require NULL to be 0? Will it become an issue in the future? What are your thoughts on the matter?
I think your professor is wrong. Per Stack Overflow mostly referring to C99, NULL need not have the same bit representation as 0 but it must compare equal to zero.

As a possible example of where a NULL pointer might not be literally all-zero bits, perhaps a machine uses a segmented memory model where any access to a given segment is forbidden. If we assume that segment might be 0xFF, then any address of a hypothetical form 0xFFxxyyzz might be considered NULL.

Even in the case where NULL is not all-zero in its representation however, if(some_ptr) is equivalent to if(some_ptr != NULL) because NULL compares equal to zero. In the hypothetical machine above, this comparison might compile to something closer to if(((uint32_t)some_ptr & 0xFF000000) != 0xFF000000).
The standard for NULL was written after many old architectures implemented NULL differently, where it would not evaluate to zero.

Your professor is correct in that you cannot "assume" NULL always evaluates to zero, however he is wrong in saying that the reason is because the standard does not define it.

To clarify, there has never been a time in ISO C history where NULL has never not evaluated to 0.
MateoConLechuga wrote:

To clarify, there has never been a time in ISO C history where NULL has never not evaluated to 0.
is the second “never” supposed to be here? So many negations:-)
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement