question about printf

P

pratik

i am working a turbo c;
the code i typed in is as follows
#include<stdio.h>
main()
{
int a=5;
printf("%d%d%d",a++,++a,a);
}
The output of the above code is very interesting.
can anyone help me with the output of the above code
Please tell me the reason for the same
Thanking you
in advance
 
T

Thomas stegen

pratik said:
i am working a turbo c;
the code i typed in is as follows
#include<stdio.h>
main()
{
int a=5;
printf("%d%d%d",a++,++a,a);
}
The output of the above code is very interesting.
can anyone help me with the output of the above code

1234 hello 42666

is one possible output

Read the FAQ! It is all there.
 
C

Case

pratik said:
i am working a turbo c;
the code i typed in is as follows
#include<stdio.h>
main()
{
int a=5;
printf("%d%d%d",a++,++a,a);
}
The output of the above code is very interesting.
can anyone help me with the output of the above code
Please tell me the reason for the same

Although I wonder why you ask a question about something
you do not supply: the output, I can tell you the reason
of your surprize.

In C the order in which function arguments are evaluated
is not specified. So you might expect to see 577 but it
might as well be 665. Here's a question for you: How many
possible results are there (on different implementations
I mean)?

Case
 
V

Vijay Kumar R Zanvar

pratik said:
i am working a turbo c;
the code i typed in is as follows
#include<stdio.h>
main()
{
int a=5;
printf("%d%d%d",a++,++a,a);
}
The output of the above code is very interesting.
can anyone help me with the output of the above code
Please tell me the reason for the same
Thanking you
in advance

This program can said to be unportable. The reason is that the order
of evaluation of arguments is unspecified. The above program, upon compilation,
gives the following warning messages.

F:\Vijay\C> gcc printf_params.c -Wall
printf_params.c: In function `main':
printf_params.c:5: warning: operation on `a' may be undefined
printf_params.c:5: warning: operation on `a' may be undefined
printf_params.c:5: warning: operation on `a' may be undefined

Consider an example,

(*fptr)( (i=2), k );

Here, which expression -- i.e., "fptr", (i=2), or k -- would be evaluated first
is unspecified by the standard. And in the same way, which argument will pushed
onto the stack -- if that is _the_ method of parameter passing -- is also
unspecified. However, it is guaranteed that all the side effects would take
place before the function is called.

Your answer is particular to the compiler you are using, though, generally
passing parameters from right to left seems to be common.

There are many ways in which parameters can be passed to a function. This
again depends on the underlying CPU architecture. Many heavy-performance based
CPUs (sorry, don't know any particulare name) may have separate sets of
registers for parameter passing; the compiler doesn't even use stack! For
maximum portability of programs, no assumptions should be made. Consider
another example:

void
mango ( register int a, int b )
{
/* .. */
}

int
main ( void )
{
int k, j;
/* .. */
mango ( k, j );
return 0;
}

Assume that the compiler fulfills the request to use a register for the
first parameter (what if only one register is available?). How about the
second parameter?
 
D

Daniel Fischer

pratik @ 2004-05-26:
printf("%d%d%d",a++,++a,a);

Order of execution is only defined for sequences, not between sequence points.
There aren't any sequence points in an argument list, and that's why the
behaviour of your code is undefined.
 
R

Richard Bos

Vijay Kumar R Zanvar said:
This program can said to be unportable. The reason is that the order
of evaluation of arguments is unspecified. The above program, upon compilation,
gives the following warning messages.

No, no, and no. It is not merely unportable; it is downright incorrect.
The reason is not merely that argument evaluation order is unspecified,
but that a is modified twice, and read one extra time, between adjacent
sequence points, causing undefined, not just unspecified, behaviour. And
it may give these messages on _your_ system, but that is far from
guaranteed.
F:\Vijay\C> gcc printf_params.c -Wall
printf_params.c: In function `main':
printf_params.c:5: warning: operation on `a' may be undefined
printf_params.c:5: warning: operation on `a' may be undefined
printf_params.c:5: warning: operation on `a' may be undefined

Note that gcc gets it almost right, and more right than you did: those
operations on a may be, indeed they definitely _are_, undefined, which
is quite a bit worse than unspecified.

Richard
 
C

Case

Richard said:
No, no, and no. It is not merely unportable; it is downright incorrect.
The reason is not merely that argument evaluation order is unspecified,
but that a is modified twice, and read one extra time, between adjacent
sequence points, causing undefined, not just unspecified, behaviour. And
it may give these messages on _your_ system, but that is far from
guaranteed.

Which two sequence points do you mean? I've read the FAQ about this
issue and if I understand it right, there are no sequence points in
a function argument list.

Kees
 
R

Richard Bos

Case said:
Which two sequence points do you mean? I've read the FAQ about this
issue and if I understand it right, there are no sequence points in
a function argument list.

Exactly. The previous sequence point is just after the previous
statement (or in this case, declaration); the next sequence point is
just before printf() is called. Those are the two adjacent sequence
points I meant; between them, a is modified twice and read three times,
of which once not for the reason of computing the modified value.

Richard
 
D

Dan Pop

In said:
i am working a turbo c;
the code i typed in is as follows
#include<stdio.h>
main()
{
int a=5;
printf("%d%d%d",a++,++a,a);
}
The output of the above code is very interesting.

Nope, you, your program and its output (if any) are very boring.

Don't post again before reading the FAQ.

Dan
 
M

Martin Ambuhl

pratik said:
i am working a turbo c;
the code i typed in is as follows
#include<stdio.h>
main()
{
int a=5;
printf("%d%d%d",a++,++a,a);
}
The output of the above code is very interesting.
can anyone help me with the output of the above code
Please tell me the reason for the same

Please check the archives on groups.google.com and the FAQ. This is so
old and boring that it's hard to keep from nodding off just reading your
post. Look up 'sequence point' in your text.

And learn to declare main as returning an int. It does so, and any
compilers implementing the current standard will require you to say so.
It is also best to return values from functions declared as returning
them, even though the new standard has given in to the illiterates and
made main act as if the return statement is there whether it is or not.
 
J

Jack Klein

Although I wonder why you ask a question about something
you do not supply: the output, I can tell you the reason
of your surprize.

In C the order in which function arguments are evaluated
is not specified. So you might expect to see 577 but it
might as well be 665. Here's a question for you: How many
possible results are there (on different implementations
I mean)?

Case

Sorry, but you are dead wrong here.

It is true that the order of evaluation of arguments to functions is
unspecified, but that has nothing to do with the possible output of
this program.

The program invokes undefined behavior, because the object a is
modified two times, and read yet a third time for a purpose other than
computing the new value, all without a sequence point.

You might get 577, you might get 665, but since the behavior is
undefined neither the C standard nor the participants of this group
place any requirements (or limits) on what may happen.

Executing this program may launch nuclear missiles, or cause your
computer to play Haydn's Trumpet Concerto (lovely piece, that), even
if it lacks a sound card and speakers. Of it could merely do the
traditional and reformat your hard disk.

Specifically see http://www.eskimo.com/~scs/C-faq/q3.2.html in the
FAQ, and the rest of the FAQ is certainly worth a read as well.
 
M

Mark McIntyre

I think reading it once will do...

yeah, sorry about that. My news-server threw some sort of fit and told my
client that it had not recieved the postings, so my client kindly kept
posting til they "got through".....
 

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
474,142
Messages
2,570,820
Members
47,367
Latest member
mahdiharooniir

Latest Threads

Top