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

[Christopher Benson-Manica]

Joona I Palaste <pa*****@cc.hel sinki.fi> spoke thus:

a[17] definitely results in UB, but a+17 doesn't.
You didn't quote the Standard ;( I know a+17 is legal, and I also
know that *(a+17) is illegal and that a+18 is also illegal...
This does not mean,
however, that a+17 will equal &b. It can, but it's not required to.

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

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[Nudge]

Christopher Benson-Manica wrote:

You didn't quote the Standard ;( I know a+17 is legal, and I also
know that *(a+17) is illegal and that a+18 is also illegal...

How can a+18 be illegal?

Would (long int)a + 42 be illegal too?

[Nudge]

bq wrote:

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"?

Your question is related to:
http://www.eskimo.com/~scs/C-faq/q6.17.html

[Chris Torek]

[Given something like "int a[17], b;" as in the subject line...]

In article <news:br******* ***@chessie.cir r.com>,
Christopher Benson-Manica <at***@nospam.c yberspace.org> asks:

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

Yes, but it the result is not useful in a strictly conforming sense.
The result is either 0 ((a+17) != &b) or 1 ((a+17) == &b), but even
if the result is 1, *(a+17) technically has undefined behavior.
In particular, a C compiler that does array bounds checking might
deliver a (compile- or run-time) array bounds error rather than
accessing the object named b.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Kevin Goodsell]

Nudge wrote:

Christopher Benson-Manica wrote:

You didn't quote the Standard ;( I know a+17 is legal, and I also
know that *(a+17) is illegal and that a+18 is also illegal...

How can a+18 be illegal?

Because the standard says so.

6.5.6 Additive operators

[#8] When an expression that has integer type is added to or
subtracted from a pointer, the result has the type of the
pointer operand.
[...]
Moreover, if the
expression P points to the last element of an array object,
the expression (P)+1 points one past the last element of the
array object, and if the expression Q points one past the
last element of an array object, the expression (Q)-1 points
to the last element of the array object. If both the
pointer operand and the result point to elements of the same
array object, or one past the last element of the array
object, the evaluation shall not produce an overflow;
otherwise, the behavior is undefined. If the result points
one past the last element of the array object, it shall not
be used as the operand of a unary * operator that is
evaluated.

In other words, you may form (but not dereference) a pointer to the area
one past the end of an array, but no farther. You cannot, in general,
create any pointer value you feel like. The behavior is undefined if you
create a "bad" pointer value - even if you don't dereference it.

Would (long int)a + 42 be illegal too?

It would be undefined if 'a' cannot be represented as a long int, or if
the addition produces overflow. Other than that, it's fine. You can
create whatever integer values you want (as long as they are in range
for the type), but the same is not true of pointers.

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Default User]

Toni Uusitalo wrote:

oh, to ensure struct variables to be contiguous you must turn off struct
padding of course.

I just checked the standard, and I failed to see the section that talks
about turning off struct padding. Perhaps you could enlighten me?


Brian Rodenborn

[Toni Uusitalo]

"Default User" <fi********@boe ing.com.invalid > wrote in message
news:3F******** *******@boeing. com.invalid...

Toni Uusitalo wrote:

oh, to ensure struct variables to be contiguous you must turn off struct
padding of course.

I just checked the standard, and I failed to see the section that talks
about turning off struct padding. Perhaps you could enlighten me?

Well I guess that isn't defined in the standard, sorry. It's only slightly
less
"wise guy trick" to use something like
#pragma packed
than what's proposed in the subject line ;-)
No real gain, only possible pain.
with respect,
Toni Uusitalo

[Martin Ambuhl]

bq wrote:

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

a[17] is a bounds error.


--
Martin Ambuhl

[Joona I Palaste]

Toni Uusitalo <to************ **@luukkudot.ko m> scribbled the following:

"Default User" <fi********@boe ing.com.invalid > wrote in message
news:3F******** *******@boeing. com.invalid...

Toni Uusitalo wrote:

> oh, to ensure struct variables to be contiguous you must turn off struct
> padding of course.
I just checked the standard, and I failed to see the section that talks
about turning off struct padding. Perhaps you could enlighten me?

Well I guess that isn't defined in the standard, sorry. It's only slightly
less
"wise guy trick" to use something like
#pragma packed
than what's proposed in the subject line ;-)
No real gain, only possible pain.

Those "wise guy tricks" are compiler-dependent and not supported by the
C standard.

--
/-- Joona Palaste (pa*****@cc.hel sinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"You have moved your mouse, for these changes to take effect you must shut down
and restart your computer. Do you want to restart your computer now?"
- Karri Kalpio

[Old Wolf]

> How can a+18 be illegal?

Consider this example (in a normal PC setting):
you have a PC with 4Gb virtual mem. The address of a[] happens to be
0xFFFFFFBC (ie. so that a[16] is the last 4 bytes of the address space).
Then doing a+18 will cause an overflow (you will end up with 0x00000004)

This would cause so many problems that it is easiest to just say 'undefined
behaviour'. Eg: int *i; for (i = a; i < a+18; ++i) {...} would not do anything.

Would (long int)a + 42 be illegal too?

Yep, assuming you meant: (long int *)a + 42