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

B

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
 
R

Rouben Rostamian

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

I have not seen reference in the C standard to any guarrantee of this
sort.

Additionally, testing the addresses of your a and b on a recent
version of gcc, it turns out that b comes just _before_ a in the
memory address space. Other compilers may behave differently.
 
M

Mark A. Odell

(e-mail address removed) (bq) wrote in

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

No.
 
A

Alan Balmer

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

No. In fact, "Hell, no!" Don't do that.
 
T

Toni Uusitalo

a and b are separate variables, compiler can locate them anywhere. only way
to ensure contiguous memory block is to use array (like your a),
struct/union or course allocate some block of memory.

with respect,
Toni Uusitalo
 
K

Kevin D. Quitt

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

Only if they are in a struct, and then there still might be some padding
between a and b.

so that "a[17]" refers to "b"?

Not only no, but "hell, no". There is no possible legitimate reason to
want to do that.
 
F

Fred L. Kleinschmidt

bq said:
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

No
 
T

Toni Uusitalo

Toni Uusitalo said:
a and b are separate variables, compiler can locate them anywhere. only way
to ensure contiguous memory block is to use array (like your a),
struct/union or course allocate some block of memory.

oh, to ensure struct variables to be contiguous you must turn off struct
padding of course.
This whole thing might make sense if you think it from the memory allocation
perspective i.e. if you for example malloc 2 different blocks of memory, for
memory management they're totally separate blocks (they might be contiguous
or they might not) etc. just as separate variables.

with respect,
Toni Uusitalo
 
C

Christopher Benson-Manica

bq said:
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"?

a[17] results in UB, I imagine. I'd be grateful if someone would
quote the Standard on this issue, however...
 
J

Joona I Palaste

Christopher Benson-Manica said:
bq said:
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"?
a[17] results in UB, I imagine. I'd be grateful if someone would
quote the Standard on this issue, however...

a[17] definitely results in UB, but a+17 doesn't. This does not mean,
however, that a+17 will equal &b. It can, but it's not required to.
 
C

Christopher Benson-Manica

Joona I Palaste said:
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?
 
N

Nudge

Christopher said:
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?
 
C

Chris Torek

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

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

Default User

Toni said:
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
 
K

Kevin Goodsell

Nudge said:
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
 
T

Toni Uusitalo

Default User said:
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
 
M

Martin Ambuhl

bq said:
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.
 
J

Joona I Palaste

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 ([email protected]) ------------- 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
 
O

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top