int a[17]; int b = -1; /* a[17] same as b guaranteed in ANSI C? */

[Christian Bau]

Apparently they don't have to be - 6.5.9:

6 Two pointers compare equal if and only if both are null pointers, both
are pointers to the same object (including a pointer to an object and a
subobject at its beginning) or function, both are pointers to one past the
last element of the same array object, or one is a pointer to one past the
end of one array object and the other is a pointer to the start of a
different array object that happens to immediately follow the first array
object in the address space.

I am surprised by that last. OTOH, 6.5.8.5:

When two pointers are compared, the result depends on the relative
locations in the address space of the objects pointed to. If two pointers
to object or incomplete types both point to the same object, or both point
one past the last element of the same array object, they compare equal. If
the objects pointed to are members of the same aggregate object, pointers
to structure members declared later compare greater than pointers to
members declared earlier in the structure, and pointers to array elements
with larger subscript values compare greater than pointers to elements of
the same array with lower subscript values. All pointers to members of the
same union object compare equal. If the expression P points to an element
of an array object and the expression Q points to the last element of the
same array object, the pointer expression Q+1 compares greater than P. In
all other cases, the behavior is undefined.


That last sentence would seem to make a comparison of a+17 and &b UB.

There is a difference between "relational operators" and "equality
operators". >= > <= < are relational operators, == and != are equality
operators. Different rules apply. (a+17) >= &b is undefined behavior,
(a+17) == &b isn't.

 

[Mark McIntyre]

Apparently they don't have to be - 6.5.9:

(two pointers compare equal if...)

.... orone is a pointer to one past the
end of one array object and the other is a pointer to the start of a
different array object that happens to immediately follow the first array
object in the address space.

I am surprised by that last.

in general its useless, as the standard doesn't typically mandate any
order in which objects are stored in memory. But think about 2-d
arrays.

OTOH, 6.5.8.5:
(snippage)
In
all other cases, the behavior is undefined.

That last sentence would seem to make a comparison of a+17 and &b UB.

No, it merely means that you can compare them, get equality and /then/
have nasal demons ensue.

Or alternatively a DR is required....

 

[Kevin D. Quitt]

Different rules apply. (a+17) >= &b is undefined behavior,
(a+17) == &b isn't.

Since b isn't an array object, it doesn't qualify for the IFF in the
above. As pointed out by someone cleverer than I, it makes sense for
multi-dimensional arrays (subobjects of the same object), but it cannot
make sense for anything else.

That does seem to call for one more clause to the IFF above: "both are
pointers to the same subobject of an object". Perhaps the Department of
Redundancy Department will make a ruling on this for us.

 

[Keith Thompson]

Since b isn't an array object, it doesn't qualify for the IFF in the
above. As pointed out by someone cleverer than I, it makes sense for
multi-dimensional arrays (subobjects of the same object), but it cannot
make sense for anything else.

That does seem to call for one more clause to the IFF above: "both are
pointers to the same subobject of an object". Perhaps the Department of
Redundancy Department will make a ruling on this for us.

It makes sense for something like this:

int foo[10];
int bar[10];

where (foo+10 == bar) may happen to be true if bar happens to
immediately follow foo in the address space. Footnote 91 makes this
explicit.

Section 6.5.8, Relational operators, says (paragraph 4):

For the purposes of these operators, a pointer to an object that
is not an element of an array behaves the same as a pointer to the
first element of an array of length one with the type of the
object as its element type.

Presumably this is intended to apply to 6.5.9 as well.

This probably calls for a DR; I'll post to comp.std.c.

 

[Keith Thompson]

Section 6.5.8, Relational operators, says (paragraph 4):

For the purposes of these operators, a pointer to an object that
is not an element of an array behaves the same as a pointer to the
first element of an array of length one with the type of the
object as its element type.

Presumably this is intended to apply to 6.5.9 as well.

This probably calls for a DR; I'll post to comp.std.c.

Yes, this called for a DR, which Clive Feature submitted over 3 years
ago. <http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/dr_215.htm>.

Thanks to Doug Gwyn for replying on comp.std.c.