regarding pointer operation in a printf function call

[sam_cit]

Hi Everyone,

I have the following code,

int main()
{
int p[] = {10,20,30,40,50};
int *i = &p[0];
printf("before : %p\n",(void*)i);
printf("1 %d %d\n",*++i,*i++);
printf("after : %p\n",(void*)i);
}

As per my understanding, arguements to a function call are passed from
right most to left most one, so in this case *i++ will be processed
first and then *++i, hence i expect the output to be

1 30 10

where as the output is

1 20 10

Can anybody explain as to why this is happening?

[Walter Roberson]

In article <11*********************@a3g2000cwd.googlegroups.c om>,
<sa*****@yahoo.co.inwrote:

I have the following code,

int main()
{
int p[] = {10,20,30,40,50};
int *i = &p[0];
printf("before : %p\n",(void*)i);
printf("1 %d %d\n",*++i,*i++);
printf("after : %p\n",(void*)i);
}

>As per my understanding, arguements to a function call are passed from
right most to left most one, so in this case *i++ will be processed
first and then *++i,

Your understanding is incorrect. C does not define the order of
evaluation of arguments to functions.

Your code is also nonconforming, as it modifies i twice between
sequence points.

I suspect you'd find this kind of topic discussed in depth in the
FAQ.

--
I was very young in those days, but I was also rather dim.
-- Christopher Priest

[sam_cit]

>
Your code is also nonconforming, as it modifies i twice between
sequence points.

Can you explain a bit more about the sequence points with some example?
I find its a bit confusing from C FAQ...

[Walter Roberson]

In article <11*********************@n67g2000cwd.googlegroups. com>,
<sa*****@yahoo.co.inwrote:

>Your code is also nonconforming, as it modifies i twice between
sequence points.

>Can you explain a bit more about the sequence points with some example?
I find its a bit confusing from C FAQ...

Sorry, I don't have time for that at the moment. Some of the details
can get confusing; even the experts here sometimes need long threads
to decide exactly what "should" happen in some of the situations.

Probably someone will offer some links that describe sequence
points in more detail.
--
Okay, buzzwords only. Two syllables, tops. -- Laurie Anderson

[mark_bluemel]

sa*****@yahoo.co.in wrote:

Your code is also nonconforming, as it modifies i twice between
sequence points.

Can you explain a bit more about the sequence points with some example?
I find its a bit confusing from C FAQ...

Ask some specific questions, with reference to the relevant part of the
FAQ and I'm sure someone(s) will try and clarify.

[Chris Dollin]

sa*****@yahoo.co.in wrote:

>Your code is also nonconforming, as it modifies i twice between
sequence points.

Can you explain a bit more about the sequence points with some example?
I find its a bit confusing from C FAQ...

If you explain what problem you have with the FAQs explanation, we
can help you understand it.

--
Chris "HO. HO. HO." Dollin
"People are part of the design. It's dangerous to forget that." /Star Cops/

[Richard Heathfield]

sa*****@yahoo.co.in said:

>

>>
Your code is also nonconforming, as it modifies i twice between
sequence points.

Can you explain a bit more about the sequence points with some example?

Imagine this is a sequence point: #SP1943#

here's some C code, ++ and * and / and + and maybe a few ()

Here's another sequence point: #SP1944#

Everything in between the two sequence points can't /start/ happening until
SP1943 has been reached. By the time we get to SP1944, it must already have
happened. But between those two points, C doesn't care what order things
happen in, as long as all the right things happen.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[jacob navia]

Richard Heathfield a écrit :

sa*****@yahoo.co.in said:

>>>Your code is also nonconforming, as it modifies i twice between
sequence points.

Can you explain a bit more about the sequence points with some example?

Imagine this is a sequence point: #SP1943#

here's some C code, ++ and * and / and + and maybe a few ()

Here's another sequence point: #SP1944#

Everything in between the two sequence points can't /start/ happening until
SP1943 has been reached. By the time we get to SP1944, it must already have
happened. But between those two points, C doesn't care what order things
happen in, as long as all the right things happen.

This is not true

[Richard Heathfield]

jacob navia said:

Richard Heathfield a écrit :

>sa*****@yahoo.co.in said:

>>>>Your code is also nonconforming, as it modifies i twice between
sequence points.
Can you explain a bit more about the sequence points with some example?

Imagine this is a sequence point: #SP1943#

here's some C code, ++ and * and / and + and maybe a few ()

Here's another sequence point: #SP1944#

Everything in between the two sequence points can't /start/ happening
until SP1943 has been reached. By the time we get to SP1944, it must
already have happened. But between those two points, C doesn't care what
order things happen in, as long as all the right things happen.

This is not true

It is possible that I am mistaken, but you have not made it clear why you
think this is so. Please do so.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:

Richard Heathfield a écrit :

>sa*****@yahoo.co.in said:

>>>>Your code is also nonconforming, as it modifies i twice between
sequence points.
Can you explain a bit more about the sequence points with some example?

Imagine this is a sequence point: #SP1943#
here's some C code, ++ and * and / and + and maybe a few ()
Here's another sequence point: #SP1944#
Everything in between the two sequence points can't /start/
happening until SP1943 has been reached. By the time we get to
SP1944, it must already have happened. But between those two points,
C doesn't care what order things happen in, as long as all the right
things happen.

This is not true

Pretend that the above was written by someone other than Richard
Heathfield, and reconsider your opinion.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Keith Thompson]

Keith Thompson <ks***@mib.orgwrites:

jacob navia <ja***@jacob.remcomp.frwrites:

>Richard Heathfield a écrit :

>>sa*****@yahoo.co.in said:
>Your code is also nonconforming, as it modifies i twice between
>sequence points.
>

Can you explain a bit more about the sequence points with some example?
Imagine this is a sequence point: #SP1943#
here's some C code, ++ and * and / and + and maybe a few ()
Here's another sequence point: #SP1944#
Everything in between the two sequence points can't /start/
happening until SP1943 has been reached. By the time we get to
SP1944, it must already have happened. But between those two points,
C doesn't care what order things happen in, as long as all the right
things happen.

This is not true

Pretend that the above was written by someone other than Richard
Heathfield, and reconsider your opinion.

That was probably not a very constructive comment; it was overly
snide.

But I'm interested in just *why* you believe it's not true.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Chris Dollin]

jacob navia wrote:

Richard Heathfield a écrit :

>Everything in between the two sequence points can't /start/ happening until
SP1943 has been reached. By the time we get to SP1944, it must already have
happened. But between those two points, C doesn't care what order things
happen in, as long as all the right things happen.

This is not true

Can you provide a counter-example?

--
Chris "HO. HO. HO." Dollin
The shortcuts are all full of people using them.

[jacob navia]

Keith Thompson a écrit :

jacob navia <ja***@jacob.remcomp.frwrites:

>>Richard Heathfield a écrit :

>>>sa*****@yahoo.co.in said:

>Your code is also nonconforming, as it modifies i twice between
>sequence points.
>

Can you explain a bit more about the sequence points with some example?

Imagine this is a sequence point: #SP1943#
here's some C code, ++ and * and / and + and maybe a few ()
Here's another sequence point: #SP1944#
Everything in between the two sequence points can't /start/
happening until SP1943 has been reached. By the time we get to
SP1944, it must already have happened. But between those two points,
C doesn't care what order things happen in, as long as all the right
things happen.

This is not true

Pretend that the above was written by someone other than Richard
Heathfield, and reconsider your opinion.

1) All this rules are "AS IF" rules, and actually
many optimizing compilers will MOVE instructions
freely from sequence points.

2) Processors have started to do "speculative execution"
too, so the moving of instructions is now done at
the hardware level

Pedantic?

Freely. Just as the many
"This is not so"

answers from heathfield are...

[Chris Dollin]

jacob navia wrote:

Keith Thompson a écrit :

>jacob navia <ja***@jacob.remcomp.frwrites:

>>>Richard Heathfield a écrit :

sa*****@yahoo.co.in said:

>>Your code is also nonconforming, as it modifies i twice between
>>sequence points.
>>
>
>Can you explain a bit more about the sequence points with some example?

Imagine this is a sequence point: #SP1943#
here's some C code, ++ and * and / and + and maybe a few ()
Here's another sequence point: #SP1944#
Everything in between the two sequence points can't /start/
happening until SP1943 has been reached. By the time we get to
SP1944, it must already have happened. But between those two points,
C doesn't care what order things happen in, as long as all the right
things happen.

This is not true

Pretend that the above was written by someone other than Richard
Heathfield, and reconsider your opinion.

1) All this rules are "AS IF" rules, and actually
many optimizing compilers will MOVE instructions
freely from sequence points.

Irrelevant: that behaviour is invisible from the inside of
a conforming program -- as you acknowledge by the "AS IF"
remark.

2) Processors have started to do "speculative execution"
too, so the moving of instructions is now done at
the hardware level

Ditto.

Pedantic?

Freely. Just as the many "This is not so"

answers from heathfield are...

His are usually from the viewpoint of the Standard, which is
after all the relevant document.

--
Chris "HO. HO. HO." Dollin
"People are part of the design. It's dangerous to forget that." /Star Cops/

[jacob navia]

Chris Dollin a écrit :

>
Ditto.

>>Pedantic?

Freely. Just as the many "This is not so"

answers from heathfield are...

His are usually from the viewpoint of the Standard, which is
after all the relevant document.

What standard?

Heathfield's standard of course.

Not the current standard but some other, choosen by him.

C'mon

Better stop this

[Chris Dollin]

jacob navia wrote:

Chris Dollin a écrit :

>>
Ditto.

>>>Pedantic?

Freely. Just as the many "This is not so"

answers from heathfield are...

His are usually from the viewpoint of the Standard, which is
after all the relevant document.

What standard?

The /C/ standard. What other ones matter here?

Heathfield's standard of course.

I don't think Richard has claimed authorship of any
standard document.

Not the current standard but some other, choosen by him.

There is a current official standard and a widely-used one.
Richard takes the reasonable view that the standard that
has widespread implementation is more useful than the one
that doesn't, if one is aiming for /portable code/. If
one instead is willing to take a more delicate position
as to which not-really-conforming-to-the-official-Standard
implementations one will use, or is willing to live with
de-facto-plus-widely-implemented-extensions, then one has
traded off portability for some amount of expressability.
Which is OK -- /if/ done mindfully and carefully.

/Both/ existing C standards say pretty much the same
thing about sequence points, yes?

--
Chris "HO. HO. HO." Dollin
A rock is not a fact. A rock is a rock.

[Random832]

2006-12-19 <ln************@nuthaus.mib.org>,
Keith Thompson wrote:

Keith Thompson <ks***@mib.orgwrites:

>jacob navia <ja***@jacob.remcomp.frwrites:

>>Richard Heathfield a écrit :
sa*****@yahoo.co.in said:
>>Your code is also nonconforming, as it modifies i twice between
>>sequence points.
>>
>
>Can you explain a bit more about the sequence points with some example?
Imagine this is a sequence point: #SP1943#
here's some C code, ++ and * and / and + and maybe a few ()
Here's another sequence point: #SP1944#
Everything in between the two sequence points can't /start/
happening until SP1943 has been reached. By the time we get to
SP1944, it must already have happened. But between those two points,
C doesn't care what order things happen in, as long as all the right
things happen.

This is not true

Pretend that the above was written by someone other than Richard
Heathfield, and reconsider your opinion.

That was probably not a very constructive comment; it was overly
snide.

But I'm interested in just *why* you believe it's not true.

I'll field this one. First of all, it ignores "as if", but that's fairly
complex to explain so a beginner-aimed explanation can be forgiven that.
A more serious problem is it completely neglects to explain (and, to
a beginner, implies the opposite) the most important pitfall for those
who _think_ they understand sequence points:

sequence points define a partial ordering.

[trm]

sa*****@yahoo.co.in schrieb:

Hi Everyone,

I have the following code,

int main()
{
int p[] = {10,20,30,40,50};
int *i = &p[0];
printf("before : %p\n",(void*)i);
printf("1 %d %d\n",*++i,*i++);
printf("after : %p\n",(void*)i);
}

As per my understanding, arguements to a function call are
passed from right most to left most one,

In C, it isn't specified how arguments are passed (but this isn't
actually relevent to the behavior you've observed).

so in this case *i++ will be processed first and then *++i,

The order in which function arguments are evaluated is unspecified,
relative to each other. All that matters is that all the necessary
evaluation occurs at some point prior to the function call; this is
an example of a "sequence point". In your code above, the relevent
sequence points are at the semicolon after the first printf (that is,
after the first printf call is complete) and the parentheses of the
second printf (that is, at the instant of the second printf call).

The idea of sequence points leads naturally to some restrictions
as to what you can legally do between them. An important one is
that you can't use ++ twice on the same object and expect the
result to be meaningful (think about it). This is an example of
"undefined behavior"; technically you can rely on nothing, or
alternately anything at all, to happen when you have undefined
behavior in your program. In other words: Don't Do That.

hence i expect the output to be

1 30 10

where as the output is

1 20 10

Can anybody explain as to why this is happening?

I probably could, but I won't, because the program has undefined
behavior, so anything is fair game. Oops, I guess that explained it.
I will however note that in the expression *i++, the increment only
has to occur somewhere before the next sequence point, but it's
not specified exactly where. (Both outputs above suggest certain
obvious, unoptimized, instruction sequences. Using a different set
of optimization settings on your compiler may result in a different
output. Or it might make your program crash, or scribble on your
hard drive.)

[Richard Heathfield]

Chris Dollin said:

<snip>

/Both/ existing C standards say pretty much the same
thing about sequence points, yes?

Yes, and if I am not mistaken, K&R C behaves in much the same way. Mr
Navia's objection is groundless, since it is rooted in the nuts and bolts
of implementation details rather than in the semantics of the language.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[trm]

Random832 schrieb:

>Richard Heathfield a écrit :
Imagine this is a sequence point: #SP1943#
here's some C code, ++ and * and / and + and maybe
a few ()
Here's another sequence point: #SP1944#
Everything in between the two sequence points can't /start/
happening until SP1943 has been reached. By the time we
get to SP1944, it must already have happened. But between
those two points, C doesn't care what order things happen in,
as long as all the right things happen.

I'll field this one. First of all, it ignores "as if", but that's
fairly complex to explain so a beginner-aimed explanation
can be forgiven that. A more serious problem is it completely
neglects to explain (and, to a beginner, implies the opposite)
the most important pitfall for those who _think_ they
understand sequence points:

sequence points define a partial ordering.

That last phrase may not be appropriate for a beginner-aimed
explanation either. In any case, I'm curious as to what way
you think Richard's implies the opposite of defining a partial
ordering. It appears to be a pretty good, if thoroughly
non-technical explanation of it to me, which seems to have
been the point. (Perhaps *I* only think I understand sequence
points.)

[Random832]

2006-12-19 <11*********************@a3g2000cwd.googlegroups.c om>,
trm wrote:

Random832 schrieb:

>>Richard Heathfield a écrit :
Imagine this is a sequence point: #SP1943#
here's some C code, ++ and * and / and + and maybe
a few ()
Here's another sequence point: #SP1944#
Everything in between the two sequence points can't /start/
happening until SP1943 has been reached. By the time we
get to SP1944, it must already have happened. But between
those two points, C doesn't care what order things happen in,
as long as all the right things happen.

I'll field this one. First of all, it ignores "as if", but that's
fairly complex to explain so a beginner-aimed explanation
can be forgiven that. A more serious problem is it completely
neglects to explain (and, to a beginner, implies the opposite)
the most important pitfall for those who _think_ they
understand sequence points:

sequence points define a partial ordering.

That last phrase may not be appropriate for a beginner-aimed
explanation either.

No, but it's important to get across somehow, or people will believe
that all they have to do is (i++,i)+i++

In any case, I'm curious as to what way you think Richard's implies
the opposite of defining a partial ordering.

It doesn't say it, but it doesn't say not, either, and the idea that you
can assign sequence points numbers like 1943, 1944, etc, might be read
as thinking "ok, first, there's sequence point 1, then after that,
sequence point 2, then sequence point 3" etc etc, all in a row.

It appears to be a pretty good, if thoroughly non-technical
explanation of it to me, which seems to have been the point. (Perhaps
*I* only think I understand sequence points.)

What I meant by "people who think they understand sequence points" is
someone who thinks (i++,i)+i++ is well-defined - after all, the first
i++ is before a sequence point.