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

[Rouben Rostamian]

In article <6c**************************@posting.google.com >,
bq <fo**********@yahoo.com> 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"?

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.

--
Rouben Rostamian

[Mark A. Odell]

fo**********@yahoo.com (bq) wrote in
news:6c**************************@posting.google.c om:

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.

--
- Mark ->
--

[Alan Balmer]

On 18 Dec 2003 08:51:00 -0800, fo**********@yahoo.com (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"?

Thanks.
bq

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

--
Al Balmer
Balmer Consulting
re************************@att.net

[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

"bq" <fo**********@yahoo.com> wrote in message
news:6c**************************@posting.google.c om...

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

[Kevin D. Quitt]

On 18 Dec 2003 08:51:00 -0800, fo**********@yahoo.com (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]"
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.

--
#include <standard.disclaimer>
_
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

[Fred L. Kleinschmidt]

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

Thanks.
bq

No

--
Fred L. Kleinschmidt
Boeing Associate Technical Fellow
Technical Architect, Common User Interface Services
M/S 2R-94 [phone]

[Toni Uusitalo]

"Toni Uusitalo" <to**************@luukkudot.kom> wrote in message
news:sA****************@reader1.news.jippii.net...

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

[Christopher Benson-Manica]

bq <fo**********@yahoo.com> spoke thus:

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

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

[Joona I Palaste]

Christopher Benson-Manica <at***@nospam.cyberspace.org> scribbled the following:

bq <fo**********@yahoo.com> spoke thus:

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.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Last year he disrespected me - and then he showed lack of respect."
- Anthony Mason

[Christopher Benson-Manica]

Joona I Palaste <pa*****@cc.helsinki.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)cyberspace.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.cirr.com>,
Christopher Benson-Manica <at***@nospam.cyberspace.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********@boeing.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.kom> scribbled the following:

"Default User" <fi********@boeing.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.helsinki.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

[ark]

"bq" <fo**********@yahoo.com> wrote in message
news:6c**************************@posting.google.c om...

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

Since a and b belong (whatever th official terminology) to different
categories -- uninitialized and initialized data respectively, a compiler
may have sound reasons to put them in different, e.g., named segments, to
optimize the startup code, for instance.

However, if both are initialized (int a=1,b=-1;) or both are not (int a,
b;), both are arrays or both are not (and both have identical types and
qualifiers) it is rather hard to imagine reasons why a compiler would prefer
an allocation different from the order of occurrence. (For the heck of it,
it could be the opposite order, but then it would break some existing code,
would it not? :)

Now, the standard quoting in this thread... undefined behavior and such...
If a function receives an int *, it has no idea where it came from, so it
(function) must allow adding any int to it (pointer). (As is usual in C, it
is the programmer's job to care about overflows.) So this "undefinedness"
looks like a lip service.

I wonder if I am correct in this assessment and also if indeed for all
practical purposes (&a+1==&b) holds true for statements <qual><type>a;
<qual><type>b;?

Thanks
- Ark

[Keith Thompson]

"ark" <ar****@comcast.net> writes:

"bq" <fo**********@yahoo.com> wrote in message
news:6c**************************@posting.google.c om...

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
Since a and b belong (whatever th official terminology) to different
categories -- uninitialized and initialized data respectively, a compiler
may have sound reasons to put them in different, e.g., named segments, to
optimize the startup code, for instance.

However, if both are initialized (int a=1,b=-1;) or both are not (int a,
b;), both are arrays or both are not (and both have identical types and
qualifiers) it is rather hard to imagine reasons why a compiler would prefer
an allocation different from the order of occurrence. (For the heck of it,
it could be the opposite order, but then it would break some existing code,
would it not? :)

Any existing code that assumes declared variables are allocated
consecutively is already badly broken.

I just tried the above code with gcc; the address of b was 4 bytes
"lower" than the address of a.

There are any number of reasons why a compiler might choose to
allocate declared variables in a seemingly arbitrary order. For
example, on some architectures it's cheaper to access variables in the
first N bytes of the current activation frame; in that case, the
compiler is likely to group smaller and/or frequently accessed
variables together.
Now, the standard quoting in this thread... undefined behavior and such...
If a function receives an int *, it has no idea where it came from, so it
(function) must allow adding any int to it (pointer). (As is usual in C, it
is the programmer's job to care about overflows.) So this "undefinedness"
looks like a lip service.
No, undefined behavior in this case is really undefined behavior. A
function receiving an int* had better be written so it won't try to
access memory outside the object it points to. If goes beyond the
bounds of the original object and steps on neighboring objects, that's
a bug. (And yes, it is the programmer's job to care about overflows;
if the programmer makes a mistake, the compiler isn't obligated to
clean up the resulting mess.)
I wonder if I am correct in this assessment and also if indeed for all
practical purposes (&a+1==&b) holds true for statements <qual><type>a;
<qual><type>b;?

Nope.

--
Keith Thompson (The_Other_Keith) 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)

[Toni Uusitalo]

"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:br**********@oravannahka.helsinki.fi...

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

"Default User" <fi********@boeing.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.

Yes, you're right.
--
/-- Joona Palaste (pa*****@cc.helsinki.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

Poor guy, I've seen some windows boxes that are in really bad shape, but
this Karri guy's machine is something ;-) must be beta of upcoming Windows
Longboot BE (bluescreen edition)?

with respect,
Toni Uusitalo

[Joona I Palaste]

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

"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:br**********@oravannahka.helsinki.fi...

/-- Joona Palaste (pa*****@cc.helsinki.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

Poor guy, I've seen some windows boxes that are in really bad shape, but
this Karri guy's machine is something ;-) must be beta of upcoming Windows
Longboot BE (bluescreen edition)?

I happen to know Karri Kalpio in person (he was my team leader at my
former job, until I got fired), and he's a really adamant Linux
enthusiast and Windows hater. So it's no wonder he said that quote -
and even gave it to me on paper so I could stick it on my monitor at
work.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"A bee could, in effect, gather its junk. Llamas (no poor quadripeds) tune
and vow excitedly zooming."
- JIPsoft

[Christopher Benson-Manica]

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

until I got fired)

*You* got fired? How'd you manage that?

(the point being that, if you, being much more competent than I, are
being fired, I may have some issues in my future...)

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

[Joona I Palaste]

Christopher Benson-Manica <at***@nospam.cyberspace.org> scribbled the following:

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

until I got fired)

*You* got fired? How'd you manage that? (the point being that, if you, being much more competent than I, are
being fired, I may have some issues in my future...)

I got fired because the company had to subsidise (sp?) to avoid going
bankrupt, and I was chosen as "least productive programmer". Not "least
competent" - least *productive*. The code I was writing was fine, but it
could just as well have been written by any other programmer on our
team.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"Stronger, no. More seductive, cunning, crunchier the Dark Side is."
- Mika P. Nieminen

[Christopher Benson-Manica]

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

I got fired because the company had to subsidise (sp?) to avoid going
bankrupt, and I was chosen as "least productive programmer". Not "least
competent" - least *productive*. The code I was writing was fine, but it
could just as well have been written by any other programmer on our
team.

So what you meant to say is that you got laid off, yes? That might be
a language thing, really. One might also say that you were
"downsized." My condolences.

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

[Joona I Palaste]

Christopher Benson-Manica <at***@nospam.cyberspace.org> scribbled the following:

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

I got fired because the company had to subsidise (sp?) to avoid going
bankrupt, and I was chosen as "least productive programmer". Not "least
competent" - least *productive*. The code I was writing was fine, but it
could just as well have been written by any other programmer on our
team.

So what you meant to say is that you got laid off, yes? That might be
a language thing, really. One might also say that you were
"downsized." My condolences.

Yes, that's right. IANAL, so I use the term "get fired" for all
occurrences of quitting one's job by someone else's decision, not one's
own. Thanks for your condolences.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"B-but Angus! You're a dragon!"
- Mickey Mouse

[Grumble]

Christopher Benson-Manica wrote:

So what you meant to say is that you got laid off, yes?

Email would appear more appropriate for such a conversation.

[Kevin Goodsell]

Joona I Palaste wrote:

Christopher Benson-Manica <at***@nospam.cyberspace.org> scribbled the following:

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

until I got fired)

*You* got fired? How'd you manage that?

(the point being that, if you, being much more competent than I, are
being fired, I may have some issues in my future...)

I got fired because the company had to subsidise (sp?) to avoid going
bankrupt, and I was chosen as "least productive programmer". Not "least
competent" - least *productive*. The code I was writing was fine, but it
could just as well have been written by any other programmer on our
team.

Man, that sucks. :(

I don't suppose they took into consideration anything other than amount
of code? So you might have been producing code that took a little longer
to write, but which saved a great deal of time in debugging and
maintenance, and was of overall better quality. But the managers
apparently aren't getting paid to look at the big picture, so you get
the boot.

I'm guessing they let go of one of their best programmers. Those kinds
of decisions are probably a major reason for their financial troubles.

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

[Toni Uusitalo]

"Joona I Palaste" <pa*****@cc.helsinki.fi> wrote in message
news:br**********@oravannahka.helsinki.fi...

Christopher Benson-Manica <at***@nospam.cyberspace.org> scribbled the

following:

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

until I got fired)

*You* got fired? How'd you manage that?

(the point being that, if you, being much more competent than I, are
being fired, I may have some issues in my future...)

I got fired because the company had to subsidise (sp?) to avoid going
bankrupt, and I was chosen as "least productive programmer". Not "least
competent" - least *productive*. The code I was writing was fine, but it
could just as well have been written by any other programmer on our
team.

SW business is cruel. I just read about the book
Everyone Else Must Fail: The Unvarnished Truth About Oracle and Larry
Ellison
from Slashdot. Name of the book is quote from Genghis Khan "It is not
sufficient that I succeed. Everyone else must fail." which Larry uses quite
often!

SW business is cruel and so are comp.lang.c moderators who are just now
planning to ban us for off-topic issues ;-)

with respect,
Toni Uusitalo Everyone Else Must Fail: The Unvarnished Truth About Oracle
and Larry Ellison
Everyone Else Must Fail: The Unvarnished Truth About Oracle and Larry
Ellison

[Les Cargill]

Kevin Goodsell wrote:

Joona I Palaste wrote:

Christopher Benson-Manica <at***@nospam.cyberspace.org> scribbled the following:

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

until I got fired)

*You* got fired? How'd you manage that?

(the point being that, if you, being much more competent than I, are
being fired, I may have some issues in my future...)

I got fired because the company had to subsidise (sp?) to avoid going
bankrupt, and I was chosen as "least productive programmer". Not "least
competent" - least *productive*. The code I was writing was fine, but it
could just as well have been written by any other programmer on our
team.

Man, that sucks. :(

I don't suppose they took into consideration anything other than amount
of code? So you might have been producing code that took a little longer
to write, but which saved a great deal of time in debugging and
maintenance, and was of overall better quality. But the managers
apparently aren't getting paid to look at the big picture, so you get
the boot.

I'm guessing they let go of one of their best programmers. Those kinds
of decisions are probably a major reason for their financial troubles.

It depends heavily on the problem domain, but financial sensitivity to
programmer productivity is not a clearly shown thing.
-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

--
Les Cargill

[Alex]

Toni Uusitalo <to**************@luukkudot.kom> wrote:

SW business is cruel and so are comp.lang.c moderators who are just now
planning to ban us for off-topic issues ;-)

We don't have moderators. If you want to be silenced, try
comp.lang.c.moderated.

Alex

[Toni Uusitalo]

"Alex" <al*******@hotmail.com> wrote in message
news:br************@ID-190529.news.uni-berlin.de...

Toni Uusitalo <to**************@luukkudot.kom> wrote:

SW business is cruel and so are comp.lang.c moderators who are just now
planning to ban us for off-topic issues ;-)

We don't have moderators. If you want to be silenced, try
comp.lang.c.moderated.

silenced? I doubt if I dare to go there. Sounds like they've got hitmen or
something...
But thanks for the warning ;-)

with respect,
Toni Uusitalo

[Anupam]

Kevin Goodsell <us*********************@neverbox.com> wrote in message news:<sW*****************@newsread2.news.pas.earth link.net>...

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?

What would the rationale be to allow a+17 to be legal yet a+18
illegal ? Is it for running trough a series of bytes and being
able to check the pointer value for beyond the bound conditions,
so that UB accesses are not made? If so what would be a similar
method for a pointer being incremented by 2 in a loop?

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

[Christopher Benson-Manica]

Anupam <an**************@persistent.co.in> spoke thus:

What would the rationale be to allow a+17 to be legal yet a+18
illegal ? Is it for running trough a series of bytes and being
able to check the pointer value for beyond the bound conditions,
so that UB accesses are not made? If so what would be a similar
method for a pointer being incremented by 2 in a loop?

Generating a pointer to one past the end of an array is allowed to
make constructs like the following legal:

char *MyStrcpy( char * const lhs, const char * rhs) {
char *p=lhs;

if( lhs != rhs ) {
while( *p++ = *rhs++ )
;
}

return lhs;
}

(reference: Efficient C Programming, Weiss. p 198)

The loop terminates when the null terminator of rhs is reached. At
that point, rhs is incremented again to one past the end of the string
rhs points to, but the resulting pointer is never dereferenced.
Allowing generation of pointers to other out-of-bounds elements is disallowed
by the Standard because of the undue burden that would be placed on
some implementors - for much the same reason, I imagine, that only one
character of pushback with ungetc() is required.

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

[Flash Gordon]

On 20 Dec 2003 11:06:48 -0800
an**************@persistent.co.in (Anupam) wrote:

Kevin Goodsell <us*********************@neverbox.com> wrote in message
news:<sW*****************@newsread2.news.pas.earth link.net>...

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?

What would the rationale be to allow a+17 to be legal yet a+18
illegal ? Is it for running trough a series of bytes and being
able to check the pointer value for beyond the bound conditions,
so that UB accesses are not made?

Yes, the one past is to allow increment then test for being past the
end. It is also because it was common practise when the first C standard
was written.
If so what would be a similar
method for a pointer being incremented by 2 in a loop?

There isn't. It is up to you to ensure that the pointer goes at most one
past the end.
--
Flash Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spam, it is real and I read it.

[Kevin D. Quitt]

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.
--
#include <standard.disclaimer>
_
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

[Kevin D. Quitt]

On Sat, 27 Dec 2003 15:40:10 -0800, Kevin D. Quitt
<KQ**********@IEEIncUNMUNG.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.
--
#include <standard.disclaimer>
_
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

[Christian Bau]

In article <l2********************************@4ax.com>,
Kevin D. Quitt <KQ**********@IEEIncUNMUNG.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.

Yes, it is legal. They don't need to be pointers to the same object.

[Christian Bau]

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

On Sat, 27 Dec 2003 15:40:10 -0800, Kevin D. Quitt
<KQ**********@IEEIncUNMUNG.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**********@IEEIncUNMUNG.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.com/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**********@IEEIncUNMUNG.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.disclaimer>
_
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**********@IEEIncUNMUNG.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**********@IEEIncUNMUNG.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_Keith) 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.org> 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_Keith) 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)