does the output depends on the compiler

[sunny]

Hi All

does the output of this command depend on the compiler.

int val=1234;
int* ptr=&val;
printf("%d %d %d",val,*ptr++,++*ptr);

O/p
i was expecting 1234,1234,1235.
but i got 1235, 1235, 1235

 

[arajak]

Hi All

does the output of this command depend on the compiler.

int val=1234;
int* ptr=&val;
printf("%d %d %d",val,*ptr++,++*ptr);

O/p
i was expecting 1234,1234,1235.
but i got 1235, 1235, 1235

 

[arajak]

Hi All

does the output of this command depend on the compiler.

int val=1234;
int* ptr=&val;
printf("%d %d %d",val,*ptr++,++*ptr);

O/p
i was expecting 1234,1234,1235.
but i got 1235, 1235, 1235

 

[=?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?=]

Hi All

does the output of this command depend on the compiler.

int val=1234;
int* ptr=&val;
printf("%d %d %d",val,*ptr++,++*ptr);

O/p
i was expecting 1234,1234,1235.
but i got 1235, 1235, 1235

Your code has undefined behaviour. You're altering ptr, and
"reading" it more than once between a sequence point, which
you should not do if you want the program to behave properly.

It's also undefined in which order arguments to functions are
evaluated.

 

[arajak]

Hi All

does the output of this command depend on the compiler.

int val=1234;
int* ptr=&val;
printf("%d %d %d",val,*ptr++,++*ptr);

O/p
i was expecting 1234,1234,1235.
but i got 1235, 1235, 1235

Its not compiler dependent, but on the implementation of printf and the
increment operator together.
**can b explained as :
** the stack maintained for printf function (where the stack grows top
to bottom):
============
++*ptr // So ++*ptr is evaluated first. --- (i)
============
*ptr++ //*ptr fetches 1235 --- because of statement (i)
============
val // val fetches 1235 --- because of statement(i)
============
char *format
============ (top of the stack)

Hence when printed it gives 1235 1235 1235

 

[=?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?=]

Its not compiler dependent, but on the implementation of printf and the
increment operator together.

No, it's compiler/platform/moon phase dependant what happens when you
invoke undefined behavior.

The explanation given below is platform dependant, and not
standarised by C.

 

[arajak]

No, it's compiler/platform/moon phase dependant what happens when you
invoke undefined behavior.

Of Course in that case, it is going to depend on the
compiler/platform.
But I answered the question assuming it to be the implementation of the
particular program(which emphasized on increment operator), which
doesnt depend on the compiler.

 

[Gordon Burditt]

does the output of this command depend on the compiler.

int val=1234;
int* ptr=&val;
printf("%d %d %d",val,*ptr++,++*ptr);

O/p
i was expecting 1234,1234,1235.
but i got 1235, 1235, 1235

Please take your expecter into the shop for repairs.
Your program invokes undefined behavior. In that
situation, *ANYTHING* can happen and nothing that does
happen is "wrong".

 

[Richard Bos]

Of Course in that case, it is going to depend on the
compiler/platform.
But I answered the question assuming it to be the implementation of the
particular program(which emphasized on increment operator), which
doesnt depend on the compiler.

And you're wrong. The result of the increment operators _when used
correctly_ doesn't depend on the compiler. When used in such a way that
it invokes undefined behaviour, the result of any C construct, including
the increment operators, depends not only on the compiler but also on
sheer luck, the nastiness of your local gremlins, and the way you
invoked your program.

Richard

 

[Ancient_Hacker]

Hi All

does the output of this command depend on the compiler.

int val=1234;
int* ptr=&val;
printf("%d %d %d",val,*ptr++,++*ptr);

O/p
i was expecting 1234,1234,1235.
but i got 1235, 1235, 1235

Aha, your expectation seems to be along the lines of "since we read
from left to right, function parameters must be evaluated likewise."

Actually, many C implementations are bousphredonic, like Hebrew and
Arabic. A picture of Kernigan and Richie may be enlightening in this
regard.

The convention varies from language to language and in C, even among
implementations. Really weird languages like Algol 60 actually pass
the code to evaluate each parameter, which can lead to extremely
bizarre results. for example you can pass:

PleaseDo( A, 100, x, y, x * y )... and Algol will cheerfully evaluate x
* y for x, y, 1 to 100 and stuff the results in A[x,y]. i.e. you can
pass EXPRESSIONS that are evaluated in the time and place of the called
function!

But I digress.

 

[Philip Potter]

Hi All

does the output of this command depend on the compiler.

int val=1234;
int* ptr=&val;
printf("%d %d %d",val,*ptr++,++*ptr);

O/p
i was expecting 1234,1234,1235.
but i got 1235, 1235, 1235

A number of things wrong with your expectations. Many of them are covered by
the comp.lang.c FAQ, question 3.2. Read this carefully.

In addition, the expression *ptr++ doesn't do what you think it does. ++
binds tighter than *, so *ptr++ is *(ptr++) - and after evaluation, the
pointer, not the pointed-to-object, is modified. You probably meant
(*ptr)++ - though I suggest you fix the other problems first.

Philip

 

[Christopher Benson-Manica]

It's also undefined in which order arguments to functions are
evaluated.

The order is unspecified, not undefined.

 

[Spiros Bousbouras]

Aha, your expectation seems to be along the lines of "since we read
from left to right, function parameters must be evaluated likewise."

Actually, many C implementations are bousphredonic, like Hebrew and
Arabic. A picture of Kernigan and Richie may be enlightening in this
regard.

You seem to have invented a new word here , "bousphredonic".
It must be new since I didn't get any Google matches. Now it
only remains to be seen whether it will catch on.

<Later thought>: You meant boustrophedonic.

 

[Dik T. Winter]

> Ancient_Hacker wrote:
>
>
> You seem to have invented a new word here , "bousphredonic".
> It must be new since I didn't get any Google matches. Now it
> only remains to be seen whether it will catch on.
>
> <Later thought>: You meant boustrophedonic.

But neither Hebrew, nor Arabic are boustrophedonic.