regarding pointer operation in a printf function call

S

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

Walter Roberson

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

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

Walter Roberson

Your code is also nonconforming, as it modifies i twice between
sequence points.
[/QUOTE]
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.
 
M

mark_bluemel

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

Chris Dollin

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

Richard Heathfield

(e-mail address removed) said:
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.
 
J

jacob navia

Richard Heathfield a écrit :
(e-mail address removed) said:




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
 
R

Richard Heathfield

jacob navia said:
Richard Heathfield a écrit :

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

Keith Thompson

jacob navia said:
Richard Heathfield a écrit :

This is not true

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

Keith Thompson

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

jacob navia

Keith Thompson a écrit :
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...
 
C

Chris Dollin

jacob said:
Keith Thompson a écrit :

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

jacob navia

Chris Dollin a écrit :
Ditto.




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
 
C

Chris Dollin

jacob said:
Chris Dollin a écrit :

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

Random832

2006-12-19 said:
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.
 
T

trm

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

Richard Heathfield

Chris Dollin said:

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

trm

Random832 said:
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.)
 

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

Forum statistics

Threads
473,755
Messages
2,569,537
Members
45,023
Latest member
websitedesig25

Latest Threads

Top