What's the value of pointer arr?

[Hill Pang]

For this satement:
ptr[func()]=1234;

if ptr is a global pointer, it would be changed by function func().
My question is:
for now, what's the value of ptr? the changed value or the un-changed
value?

 

[Shao Miller]

For this satement:
ptr[func()]=1234;

if ptr is a global pointer, it would be changed by function func().
My question is:
for now, what's the value of ptr? the changed value or the un-changed
value?

That is equivalent to:

*(ptr + func() ) = 1234;

The operands to the addition operator are unsequenced, so they can be
evaluated in any order; you cannot portably rely on a particular
order.

 

[Angel]

For this satement:
ptr[func()]=1234;

if ptr is a global pointer, it would be changed by function func().

Nope, it wouldn't. There is nothing in this statement that changes the
value of ptr.

The array index [] works as a dereference; this statement changes one
of the objects in the array ptr points to, provided of course that it
does point to an array of objects and the index value yielded by func()
is within range for that array. Otherwise, the behaviour is undefined.

My question is:
for now, what's the value of ptr? the changed value or the un-changed
value?

The value of ptr can't be determined by this statement alone and is not
changed by it in any way.

 

[James Kuyper]

For this satement:
ptr[func()]=1234;

if ptr is a global pointer, it would be changed by function func().

It would have been helpful to provide an example, so we'd have a better
idea what you're talking about. The following example seems to match
your description; is it an appropriate example?

int first[3];
int second[3];
int *ptr = first;

int func(void)
{
if(ptr==first)
ptr = second);
else
ptr = first;
return 1;
}

My question is:
for now, what's the value of ptr? the changed value or the un-changed
value?

The statement
ptr[func()]=1234;

has no sequence points separating the evaluation of 'ptr' and the
evaluation of 'func()'. This is perhaps clearer if you consider the
following three statements, all of which are exactly equivalent to yours:

*(ptr + func()) = 1234;
*(func() + ptr) = 1234;
func()[ptr] = 1234;

Because there's no intervening sequence point, the value of ptr that is
used in the expression might be the one before the function call, or the
one after the function call. Both are equally valid ways of translating
your code. Which makes your code a very bad way of expressing what you
want to do. If you need the evaluations to occur in a particular order
(which will (almost?) always be the case), the way to do so is to say so
explicitly:

int idx = func();
ptr[idx] = 1234;

or
int *copy = ptr;
copy[func()] = 1234;

 

[Phil Carmody]

For this satement:
ptr[func()]=1234;

if ptr is a global pointer, it would be changed by function func().

It would have been helpful to provide an example, so we'd have a better
idea what you're talking about. The following example seems to match
your description; is it an appropriate example?

int first[3];
int second[3];
int *ptr = first;

int func(void)
{
if(ptr==first)
ptr = second);
else
ptr = first;
return 1;
}

My question is:
for now, what's the value of ptr? the changed value or the un-changed
value?

The statement
ptr[func()]=1234;

has no sequence points separating the evaluation of 'ptr' and the
evaluation of 'func()'.

The evaluation of func() has several sequence points, one on entry and
one on exit at least. However, the sequence points it has are not ordered
relative to the evaluation of ptr.

Phil

 

[Shao Miller]

My question is:
for now, what's the value of ptr? the changed value or the un-changed
value?

The statement
ptr[func()]=1234;

has no sequence points separating the evaluation of 'ptr' and the
evaluation of 'func()'.

The evaluation of func() has several sequence points, one on entry and
one on exit at least. However, the sequence points it has are not ordered
relative to the evaluation of ptr.

I believe that in C1X, those sequence points you mention are
sequenced before or after 'ptr' is evaluated, but not "during."

 

[Eric Sosman]

For this satement:
ptr[func()]=1234;

if ptr is a global pointer, it would be changed by function func().
My question is:
for now, what's the value of ptr? the changed value or the un-changed
value?

Unspecified.

But not "undefined," as far as I can see. The sub-expression
`ptr' can be evaluated before or after `func()', but not "during"
it. Since there's a sequence point before `func()' is called and
at least one more after any modification it might make to `ptr',
the evaluation of `ptr' is either before the first sequence point
or after the second, and hence separated from any modification that
occurs between them. Thus, I do not believe this falls afoul of
the "only to determine the value to be stored" rule (6.5p2).

 

[Eric Sosman]

For this satement:
ptr[func()]=1234;

if ptr is a global pointer, it would be changed by function func().
My question is:
for now, what's the value of ptr? the changed value or the un-changed
value?

Unspecified.

But not "undefined," as far as I can see. The sub-expression
`ptr' can be evaluated before or after `func()', but not "during"
it. [...]

"Upon further review," as they say in American football, I'll
retract "unspecified" and vote for "undefined" after all. Although
`ptr' cannot be evaluated "during" func(), its evaluation could
"straddle" that of func(), part before and part after. For example,
consider a system where pointers are two or more "atoms" long, and
must be loaded with two or more separate operations. A possible
translation of your code could be "Fetch some of ptr, call func(),
fetch the rest of ptr, combine the pieces of ptr and the value from
func() to determine where to store 1234." Changing `ptr' in the
middle of this sequence could have unpleasant results.

 

[Tim Rentsch]

For this satement:
ptr[func()]=1234;

if ptr is a global pointer, it would be changed by function func().

It would have been helpful to provide an example, so we'd have a better
idea what you're talking about. The following example seems to match
your description; is it an appropriate example?

int first[3];
int second[3];
int *ptr = first;

int func(void)
{
if(ptr==first)
ptr = second);
else
ptr = first;
return 1;
}

My question is:
for now, what's the value of ptr? the changed value or the un-changed
value?

The statement
ptr[func()]=1234;

has no sequence points separating the evaluation of 'ptr' and the
evaluation of 'func()'.

The evaluation of func() has several sequence points, one on entry and
one on exit at least. However, the sequence points it has are not ordered
relative to the evaluation of ptr.

The order of evaluation is unspecified, but there is a
linear order for these two evaluations. This requirement is
spelled out more exactly in text appearing in C1X, but the
"atomic"-ness of function calls has been part of standard C
much longer, going back to DR 087 in 1993.

 

[Tim Rentsch]

For this satement:
ptr[func()]=1234;

if ptr is a global pointer, it would be changed by function func().
My question is:
for now, what's the value of ptr? the changed value or the un-changed
value?

Unspecified.

But not "undefined," as far as I can see. The sub-expression
`ptr' can be evaluated before or after `func()', but not "during"
it. [...]

"Upon further review," as they say in American football, I'll
retract "unspecified" and vote for "undefined" after all. Although
`ptr' cannot be evaluated "during" func(), its evaluation could
"straddle" that of func(), part before and part after. For example,
consider a system where pointers are two or more "atoms" long, and
must be loaded with two or more separate operations. A possible
translation of your code could be "Fetch some of ptr, call func(),
fetch the rest of ptr, combine the pieces of ptr and the value from
func() to determine where to store 1234." Changing `ptr' in the
middle of this sequence could have unpleasant results.

Your first impression was right. The current Standard
doesn't say this clearly (the new text in C1X does),
but not too long after C90 the difference between
function calls and other kinds of sequence points
was brought out in DR 087.