does a program work in all cases?

[Keith Thompson]

[#3] An integer constant expression with the value 0, or
such an expression cast to type void *, is called a null
pointer constant.

6.3.2.3 seems to
suggest that uncasted 0 is not a null pointer constant.

No, it doesn't suggest that at all.

Gentlemen, are you discussing CPLUSPLUS???
Because "zero equals NULL" as far as I know
only applies there.....

No, we're discussing C. In C, an integer constant expression with the
value 0 is a null pointer constant. (This does not imply that a null
pointer has an all-bits-zero representation). See section 5 of the
comp.lang.c FAQ.

(C++ may or may not have different rules.)

 

[pete]

Both are logical operators, and all logical operators return either
0 or 1.

Yes, but ..., (!p) is equivalent to (p == 0).

Walter Roberson wrote, and you snipped:
"!p is just shorthand for p!=0",
which is what malc was disputing.

 

[malc]

[..snip..]

Read 6.3.2.3 again:

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

The integer constant 0, without a cast, most certainly is a null
pointer constant.

Yes, i missed the `or' part hence the confusion.

[..snip..]

There's a great deal of confusion about null pointer constants, but
there's really not much room for debate. I know of a couple of subtle
issues with respect to the standard's definition (see below), but
nothing that a typical programmer needs to worry about. Section 5 of
the comp.lang.c FAQ, <http://www.c-faq.com/>, explains null pointers,
null pointer constants, and the NULL macro quite well.

Thank you for the pointer.

The subtle points (feel free to stop reading right now):

According to the language definition, at least as I interpret it, an
unadorned integer constant 0 is by definition a "null pointer
constant" even if it doesn't appear in a context that requires one.
For example, this:
int x = 0;
contains a null pointer constant, even though there's not a pointer
object or value in sight. This is a bit counterintuitive, but it's
really not a problem; just ignore the fact that it's a null pointer
constant unless you need it to be one.

Heh, this is part of the problem Herb Sutter and Bjarne Stroustrup are
trying to address in their nullptr proposal for C++. Sorry for OT.

The definition of a parenthesized expression says that it has certain
of the same properties as the unparenthesized expression, namely its
type, its value, whether it's an lvalue, whether it's a function
designator, and whether it's a void expression. Note that the list of
properties does *not* include whether it's a null pointer constant.
So, strictly speaking, (void*)0 is a null pointer constant, but
((void*)0) is not. But the standard requires definitions of
object-like macros in the standard library to be fully parenthesized
where necessary. So, by a strict reading of the standard, NULL cannot
expand to (void*)0 because it's not fully parenthesized (consider
sizeof NULL), but it can't expand to ((void*)0) because that's not a
null pointer constant. It's obvious, though, that a parenthesized
null pointer constant is *intended* to be a null pointer constant, and
many implementations just go ahead and define NULL as ((void*)0).
(One could argue, I suppose, that treating ((void*)0) as a null
pointer constant is an implementation-specific extension.)

If i understand you correctly you are implying that null pointer
constant has a type (and/or) value that is distinct from any other?
(otherwise standard is in the clear afaics)

In any case that was interesting, thank you.

 

[pete]

malc wrote:

[#3] An integer constant expression with the value 0, or
such an expression cast to type void *, is called a null
pointer constant.

Gentlemen, are you discussing CPLUSPLUS???
Because "zero equals NULL" as far as I know
only applies there.....

(0 == NULL) is always true in C.

What do you think malc is quoting above?

 

[malc]

Yes, but ..., (!p) is equivalent to (p == 0).

Standard says that it is equivalent to (0==p), i'm not really sure if
== is commutative in all contexts it is allowed

Walter Roberson wrote, and you snipped:
"!p is just shorthand for p!=0",
which is what malc was disputing.

Indeed. Another question whether it's always true that:
x==y === !(x!=y)

 

[CBFalconer]

Yes, but ..., (!p) is equivalent to (p == 0).

Walter Roberson wrote, and you snipped:
"!p is just shorthand for p!=0",
which is what malc was disputing.

A case of my failure to read with a suitably suspicious attitude

 

[Peter Nilsson]

if (!(arr)) {
printf("Failed to allocate memory\n");

[...]
You also should really go if (arr != NULL) because !NULL is not
necessarily true on all platforms.

Yes, it is. The expressions (arr != NULL)
and (!arr) are exactly equivalent, assuming arr is a pointer.

ITYM the expressions (arr == NULL) and (!arr) are equivalent...

 

[Keith Thompson]

If i understand you correctly you are implying that null pointer
constant has a type (and/or) value that is distinct from any other?

No, not at all.

A null pointer constant has whatever type it has as an expression.
It's either "[a]n integer constant expression with the value 0", which
has a type dependent on the form of the expression (0 is int, 0L is
long int, etc.), or "such an expression cast to type void*", which has
type void*.

A null pointer constant may be converted to a pointer type, either
explicitly or implicitly; the result of the conversion has that
pointer type.

Implicit conversions can make this tricky. For example:

double *p;
p = 0;

The expression 0, by itself, has type int. Since it's a null pointer
constant, it may be (and in this case is) implicitly converted to
double*; the result of the conversion is of type double*. The int
expression and the double* expression happen to look exactly alike:
the single token 0. (You can imagine an invisible conversion
operator, but the standard doesn't describe it in those terms.)

 

[Keith Thompson]

if (!(arr)) {
printf("Failed to allocate memory\n"); [...]
You also should really go if (arr != NULL) because !NULL is not
necessarily true on all platforms.

Yes, it is. The expressions (arr != NULL)
and (!arr) are exactly equivalent, assuming arr is a pointer.

ITYM the expressions (arr == NULL) and (!arr) are equivalent...

YTWIM. (Yes, that's what I meant.)

But hey, what's a logical inversion among friends?

To summarize: OOPS!

 

[pete]

pete <[email protected]> writes:

(!p) is equivalent to (p == 0).

Standard says that it is equivalent to (0==p), i'm not really sure if
== is commutative in all contexts it is allowed

Another question whether it's always true that:
x==y === !(x!=y)

Think about it.

 

[Richard Heathfield]

malc said:

pete <[email protected]> writes:

Standard says that it is equivalent to (0==p), i'm not really sure if
== is commutative in all contexts it is allowed

It is.

[...] Another question whether it's always true that:
x==y === !(x!=y)

It is. x!=y yields 0 if they are equivalent, but 1 if they are not. !0 is 1,
and !1 is 0. So !(x!=y) yields 1 if they are equivalent, but 0 if they are
not, just like x==y.

 

[Random832]

[#3] An integer constant expression with the value 0, or
such an expression cast to type void *, is called a null
pointer constant.

6.3.2.3 seems to
suggest that uncasted 0 is not a null pointer constant.

No, it doesn't suggest that at all.

Why? The condition is clearly spelled out, the expression must be
cast to type void * to be called null pointer constant.

http://dictionary.reference.com/search?q=or

 

[Random832]

malc wrote:

[#3] An integer constant expression with the value 0, or
such an expression cast to type void *, is called a null
pointer constant.

6.3.2.3 seems to
suggest that uncasted 0 is not a null pointer constant.
No, it doesn't suggest that at all.

Gentlemen, are you discussing CPLUSPLUS???
Because "zero equals NULL" as far as I know
only applies there.....

No, we're discussing C. In C, an integer constant expression with the
value 0 is a null pointer constant. (This does not imply that a null
pointer has an all-bits-zero representation). See section 5 of the
comp.lang.c FAQ.

(C++ may or may not have different rules.)

OT: C++ misses entirely the point of having void * - I think, though,
that it doesn't actually forbid NULL expanding to ((void*)0) - a
compiler could special-case this to not be an error when assigned to
other pointers.

 

[Random832]

[...] Another question whether it's always true that:
x==y === !(x!=y)

It is. x!=y yields 0 if they are equivalent, but 1 if they are not. !0 is 1,
and !1 is 0. So !(x!=y) yields 1 if they are equivalent, but 0 if they are
not, just like x==y.

What if x is not a number? Don't the comparison operators behave
strangely in those cases? I know that x >= y and x < y are then both
false at least.

 

[malc]

Think about it.

I am well aware of De Morgan's laws. What i do not know if there might
be a case (covered by standard) where `==' is defined for given `x' and
`y' and `!=' not.

 

[Richard Heathfield]

Random832 said:

[...] Another question whether it's always true that:
x==y === !(x!=y)

It is. x!=y yields 0 if they are equivalent, but 1 if they are not. !0 is
1, and !1 is 0. So !(x!=y) yields 1 if they are equivalent, but 0 if they
are not, just like x==y.

What if x is not a number?

If it's not a number, it's a pointer. If it's a pointer, so is y.

If the pointers point to the same object, they will compare equal (whether
or not they have the same object representation).

Don't the comparison operators behave
strangely in those cases? I know that x >= y and x < y are then both
false at least.

C&V, please.

 

[Default User]

Random832 wrote:

OT: C++ misses entirely the point of having void * - I think, though,
that it doesn't actually forbid NULL expanding to ((void*)0) - a
compiler could special-case this to not be an error when assigned to
other pointers.

It does forbid that, for the very good reason that there is no implicit
conversion from void* to any other pointer. That's why a cast is
required for malloc() in C++.

Were NULL defined as that way, it would require diagnostics every time
it was assigned to a non-void pointer.




Brian

 

[Random832]

Random832 said:

[...] Another question whether it's always true that:
x==y === !(x!=y)

It is. x!=y yields 0 if they are equivalent, but 1 if they are not. !0 is
1, and !1 is 0. So !(x!=y) yields 1 if they are equivalent, but 0 if they
are not, just like x==y.

What if x is not a number?

If it's not a number, it's a pointer. If it's a pointer, so is y.

Sorry I wasn't clear; by "not a number", I meant "Not a Number".

If the pointers point to the same object, they will compare equal (whether
or not they have the same object representation).


C&V, please.

OK, C doesn't specify this. I think that if __STDC_IEC_559__ is defined
though, it's needed.

Apparently != is always true, rather than always false, when presented
with a NAN.

C itself, without IEC 559, apparently only requires "1 if the specified
relation is true and 0 if it is false", without defining in what
circumstances a given relation is true or false (since, in all cases not
involving NANs, it should be self-evident)

 

[Richard Heathfield]

Random832 said:

Sorry I wasn't clear; by "not a number", I meant "Not a Number".

Oh, I see! In that case, I'll duck. My knowledge of FPA isn't
sufficient for me to wax confident about NaNs because, in Real Life, I have
had very little use for FPA of any complexity. I suppose I could schildt my
way through the docs for you, but what would be the point of that?

<snip>

 

[Random832]

Random832 wrote:




It does forbid that, for the very good reason that there is no implicit
conversion from void* to any other pointer.

Right. Like I said, it misses the point of having void * at all.