pointer equality

[Keith Thompson]

The key is in the "or to a pointer to void" words in A7.10. It means
you can compare a pointer to an object and a pointer to non-object for
equality, so the restriction that both pointers must point inside the
same object no longer applies. It's still not immediately obvious that
you can compare for equality object pointers that point to different
objects, but, since p == (void *)q is allowed regardless of where q
points (the text under discussion doesn't impose restrictions on the void
pointer operand), it follows that p == q should be valid, too (assuming
that the types of p and q allow direct comparison for equality).

Sorry, I'm not convinced. Someone who hasn't assumed that p == q is
valid is not likely to infer it from the pointer-to-void rule. If the
"additional possibilities" clause is meant to be exhaustive, it's
pretty clear (to me) that it *deosn't* cover p == q, where p and q are
pointers to distinct non-adjacent objects; neither p nor q is a
pointer to void.

Given that p == (void*)q is valid, it certainly makes sense that p == q
*should* be valid, but it's not stated, and there are too many other
places in the language where the "it makes sense that it should be
valid" rule breaks down.

 

[Keith Thompson]

Then it is exactly as the C Standard says. Relational operators must
_not_ be used to compare pointers to different objects or compare any
pointer to a NULL pointer,
Agreed.

equality operators are perfectly legal to
compare pointers to different objects and NULL pointers.

I agree (that's clearly the intent, and it says so in the standard),
but K&R2 just doesn't say so.

I think we're all in agreement that relational operators (<, <=, >,>=)
between pointers to distinct non-adjacent objects invoke undefined
behavior, and that K&R2 A7.9 says so sufficently clearly, so I won't
re-type that section.

Here's the entirety of section A7.10 of K&R2 (first printing, but
there are no errata for that section). I've double checked for typos,
but I can't guarantee perfection. I haven't tried to reproduce
italics or bold-face, and the layout differs but not significantly.
I'll use "[section]" for the section symbol (that funky character that
looks like two intertwined S's).

A7.10 Equality Operators

equality-expression:
relational-expression
equality-expression == relational-expression
equality-expression != relational-expression

The == (equal to) and the != (not equal to) operators are analogous
to the relational operators except for their lower precedence.
(Thus a<b == c<d is 1 whenever a<b and c<d have the same
truth-value.)

The equality operators follow the same rules as the relational
operators, but permit additional possibilities: a pointer may
be compared to a constant integral expression with value 0,
or to a pointer to void. See [section]A6.6.

I presume that the listed "additional possibilities" are intended to
be exhaustive; this is a reference manual, after all.

Suppose p and q are pointers to distinct non-adjacent objects of the
same type. Where in A7.10 (or anywhere else in Appendix A) is it
stated that, although p < q is undefined, p == q is well-defined?
(Pretend that you don't already know that before reading it.)

 

[Keith Thompson]

Given that p == (void*)q is valid, it certainly makes sense that p == q
*should* be valid, but it's not stated, and there are too many other
places in the language where the "it makes sense that it should be
valid" rule breaks down.

I sent an e-mail message to Dennis Ritchie pointing out this minor
oversight in section A7.10 of K&R2. (I credited Ike Naar for finding
it.) He agrees that it's an error, and will add it to the errata.