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

[bq]

In the code
int a[17];
int b = -1;
does ANSI C guarantee that "b" is located in memory right after "a[16]"
so that "a[17]" refers to "b"?

Thanks.
bq

[Christian Bau]

In article <9t************ *************** *****@4ax.com>,
Kevin D. Quitt <KQ**********@I EEIncUNMUNG.com > wrote:

On Sat, 27 Dec 2003 15:40:10 -0800, Kevin D. Quitt
<KQ**********@I EEIncUNMUNG.com > wrote:

On Thu, 18 Dec 2003 18:55:37 +0000 (UTC), Christopher Benson-Manica
<at***@nospam. cyberspace.org> wrote:

Is (a+17)==&b a legal comparison?

No. They aren't pointers to the same object.

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]

On Sat, 27 Dec 2003 16:02:38 -0800, in comp.lang.c , Kevin D. Quitt
<KQ**********@I EEIncUNMUNG.com > wrote:

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....

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.c om/ms3/bchambless0/welcome_to_clc. html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Kevin D. Quitt]

On Sun, 28 Dec 2003 00:22:30 +0000, Christian Bau
<ch***********@ cbau.freeserve. co.uk> wrote:

In article <9t************ *************** *****@4ax.com>,
Kevin D. Quitt <KQ**********@I EEIncUNMUNG.com > wrote:

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.

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.
--
#include <standard.discl aimer>
_
Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up
Per the FCA, this address may not be added to any commercial mail list

[Keith Thompson]

Kevin D. Quitt <KQ**********@I EEIncUNMUNG.com > writes:

On Sun, 28 Dec 2003 00:22:30 +0000, Christian Bau
<ch***********@ cbau.freeserve. co.uk> wrote:

In article <9t************ *************** *****@4ax.com>,
Kevin D. Quitt <KQ**********@I EEIncUNMUNG.com > wrote:

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.

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.

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 (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)

[Keith Thompson]

Keith Thompson <ks***@mib.or g> writes:
[...]

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.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)