tags:

views:

194

answers:

4

I'm asking because of the discussion that's been provoked in this thread.

Trying to have a serious back-and-forth discussion using comments under other people's replies is not easy or fun. So I'd like to hear what our C experts think without being restricted to 500 characters at a time.

The C standard has precious few words to say about NULL and null pointer constants. There's only two relevant sections that I can find. First:

3.2.2.3 Pointers

An integral constant expression with the value 0, or such an expression cast to type void * , is called a null pointer constant. If a null pointer constant is assigned to or compared for equality to a pointer, the constant is converted to a pointer of that type. Such a pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function.

and second:

4.1.5 Common definitions

The macros are

NULL

which expands to an implementation-defined null pointer constant;

The question is, can NULL expand to an implementation-defined null pointer constant that is different from the ones enumerated in 3.2.2.3?

In particular, could it be defined as:

#define NULL __builtin_magic_null_pointer

Or even:

#define NULL ((void*)-1)

My reading of 3.2.2.3 is that it specifies that an integral constant expression of 0, and an integral constant expression of 0 cast to type void* must be among the forms of null pointer constant that the implementation recognizes, but that it isn't meant to be an exhaustive list. I believe that the implementation is free to recognize other source constructs as null pointer constants, so long as no other rules are broken.

So for example, it is provable that

#define NULL (-1)

is not a legal definition, because in

if (NULL) 
   do_stuff(); 

do_stuff() must not be called, whereas with

if (-1)
   do_stuff();

do_stuff() must be called; since they are equivalent, this cannot be a legal definition of NULL.

But the standard says that integer-to-pointer conversions (and vice-versa) are implementation-defined, therefore it could define the conversion of -1 to a pointer as a conversion that produces a null pointer. In which case

if ((void*)-1) 

would evaluate to false, and all would be well.

So what do other people think?

I'd ask for everybody to especially keep in mind the "as-if" rule described in 2.1.2.3 Program execution. It's huge and somewhat roundabout, so I won't paste it here, but it essentially says that an implementation merely has to produce the same observable side-effects as are required of the abstract machine described by the standard. It says that any optimizations, transformations, or whatever else the compiler wants to do to your program are perfectly legal so long as the observable side-effects of the program aren't changed by them.

So if you are looking to prove that a particular definition of NULL cannot be legal, you'll need to come up with a program that can prove it. Either one like mine that blatantly breaks other clauses in the standard, or one that can legally detect whatever magic the compiler has to do to make the strange NULL definition work.

Steve Jessop found an example of way for a program to detect that NULL isn't defined to be one of the two forms of null pointer constants in 3.2.2.3, which is to stringize the constant:

#define stringize_helper(x) #x
#define stringize(x) stringize_helper(x) 

Using this macro, one could

puts(stringize(NULL));

and "detect" that NULL does not expand to one of the forms in 3.2.2.3. Is that enough to render other definitions illegal? I just don't know.

Thanks!

+1  A: 

Well, I've found a way to prove that

#define NULL ((void*)-1)

is not a legal definition of NULL.

int main(void) 
{ 
   void (*fp)() = NULL;   
}

Initializing a function pointer with NULL is legal and correct, whereas...

int main(void) 
{ 
   void (*fp)() = (void*)-1;   
}

...is a constraint violation that requires a diagnostic. So that's out.

But the __builtin_magic_null_pointer definition of NULL wouldn't suffer that problem. I'd still like to know if anybody can come up with a reason why it can't be.

janks
Why is your second initialization a constraint violation that requires a diagnostic? *If* a conforming compiler is allowed to announce that `(void*)-1` is a null pointer constant (which I doubt), then my suspicion (without know what text you're looking at), is that it would be a legal initialization, because null pointer constants by definition convert to any pointer type, including pointer-to-function.
Steve Jessop
You could very well be right about that, heh. I had in mind the first clause of `3.2.2.3 Pointers`, which says `A pointer to void may be converted to or from a pointer to any incomplete or object type...`. A function is neither an incomplete nor an object type. But now I see the final clause of `3.3.16.1 Simple assignment ... Contraints ... One of the following shall hold ... the left operand is a pointer and the right is a null pointer constant`. If the implementation defined ((void*)-1) as a valid null pointer constant, then that would seem to permit it. Reading the standard isn't easy
janks
A: 

An integral constant expression with the value 0, or such an expression cast to type void * , is called a null pointer constant.

NULL which expands to an implementation-defined null pointer constant;

therefore either

NULL == 0

or

NULL == (void *)0

ammoQ
But does the first sentence preclude other forms of the null pointer constant? Or is it the minimum set of null pointer constants that must be recognized by the implementation?
janks
@ammoQ: you haven't listed all possibilities. The following are also integral constant expressions with the value 0: `0x0`, `0L`, `(1-1)`, `(12^12)`, and depending on implementation possibly `(2*INT_MIN)`.
Steve Jessop
@janks: You are confusing two different things. In the *source code* the only valid value of `NULL` is zero (or zero cast to `void *`). However, this code may *compile* to a different representation, without any need for the machine to actually support zero as an equivalent.
Arkku
@Arkku: I'm well aware of the distinction between value and representation. Can you quote any standardese to support the claim that 0 or 0 cast to void* are the ONLY legal forms for the null pointer constant to take in the source code? `3.2.2.3` quoted above says nothing about "only", and doesn't otherwise imply to me that it is an exhaustive list. Is there another part of the standard that you know of that clarifies this?
janks
@janks: See my answer for references to the standard.
Arkku
Steve: that's why I used the == operator, instead of assuming a #define
ammoQ
janks: IMO the first sentence precludes other forms of null pointer constants.
ammoQ
+5  A: 

In the C99 standard, 7.17.3 states that NULL “expands to an implementation defined null pointer constant”. Meanwhile 6.3.2.3.3 defines null pointer constant as “an integer constant expression with the value 0, or such an expression cast to type void *”. As there is no other definition for a null pointer constant, a conforming definition of NULL must expand to an integer constant expression with the value zero (or this cast to void *).

Further quoting from the C FAQ question 5.5 (emphasis added):

Section 4.1.5 of the C Standard states that NULL “expands to an implementation-defined null pointer constant,” which means that the implementation gets to choose which form of 0 to use and whether to use a `void *` cast; see questions 5.6 and 5.7. “Implementation-defined” here does not mean that NULL might be #defined to match some implementation-specific nonzero internal null pointer value.

It makes perfect sense; since the standard requires a zero integer constant in pointer contexts to compile into a null pointer (regardless of whether or not the machine's internal representation of that has a value of zero), the case where NULL is defined as zero must be handled anyhow. The programmer is not required to type NULL to obtain null pointers; it's just a stylistic convention (and may help catch errors e.g. when a NULL defined as (void *)0 is used in a non-pointer context).

Edit: One source of confusion here seems to be the concise language used by the standard, i.e. it does not explicitly say that there is no other value that might be considered a null pointer constant. However, when the standard says “…is called a null pointer constant”, it means that exactly the given definitions are called null pointer constants. It does not need to explicitly follow every definition by stating what is non-conforming when (by definition) the standard defines what is conforming.

Arkku
The C99 text you've quoted is the same as the C89 text, and the FAQ isn't normative. You might be onto something with the argumentation regarding the absence of other definitions. I'll have to look further into that.
janks
Edited the answer to address the absence of other definitions. One way to think about it would be to look at other parts of the standard; when there are implementation-defined possibilities involved, it's always explicitly stated. The language in the standard aims to be exact, there's no room for speculating about things left unsaid.
Arkku
One may also consider how the definition of *null pointer constant* would look if other possibilities were allowed. It would not say “X is called…” and then give no mention of other possibilities if there were any, because that would allow arbitrary things (like your neighbour's cat) to be called null pointer constants. If there were other options, it would define what exactly *can* be a null pointer constant (e.g. "any implementation-defined integer constant expression or such an expression cast to void”).
Arkku
But the standard has plenty of examples of completely restricted implemented-defined behaviour (whether char is signed or unsigned, two choices), as well as completely unrestricted implementation-defined behaviour (maximum number of case statements in a select, additional forms of `main()` and `main(int, char**)`, representation of floats, etc). Why is there a problem with unbounded lists of arbitrary things? Implementation-defined means the implementation must define them somewhere, so they'll be exhaustively documented by the implementation at the end of the day, no matter what it chooses
janks
That's my point; in each of these implementation-defined cases the standard specifies that they are up to the implementation. With null pointer constants, only the two possibilities are given. The definition of NULL says that it *is* a null pointer constant, but this time explicitly states that the implementor can decide which null pointer constant to use. The definition of null pointer constant does not leave any room to assume that there might be other possibilities.
Arkku
To borrow terms from OOP; NULL is defined as having to conform to a NullPointerConstant interface, but the definition of NullPointerConstant interface only allows these specific types of implementations.
Arkku
A: 

The null pointer constant must evaluate 0, otherwise expressions like !ptr would not work as expected.

The NULL macro expands to a 0-valued expression; AFAIK, it always has.

John Bode
What would prevent the compiler from re-writing `!ptr` as `ptr == __magic_null` if that is what it used? All that is required of the compiler is that it make !ptr work somehow. It doesn't have to work as-if by treating ptr as an integer.
janks