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

[ark]

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]

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.

 

[Toni Uusitalo]

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

Yes, you're right.

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

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]

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

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

 

[Joona I Palaste]

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

 

[Christopher Benson-Manica]

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.

 

[Grumble]

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

Email would appear more appropriate for such a conversation.

 

[Joona I Palaste]

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.

 

[Kevin Goodsell]

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

 

[Toni Uusitalo]

Christopher Benson-Manica <[email protected]> scribbled the following:



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]

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.

 

[Alex]

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]

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]

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?

 

[Christopher Benson-Manica]

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.

 

[Flash Gordon]

On 20 Dec 2003 11:06:48 -0800

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.

 

[Kevin D. Quitt]

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

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

 

[Kevin D. Quitt]

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.

 

[Christian Bau]

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

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