evaluation of arguments to a function

[Greenhorn]

Hi,
From man pages in unix it seem the behavior in below usage of
printf() is undefined. But, is there something to be noted from the
output of the below line.

printf("%d %d", i = printf("order of printing"),j = printf("Test"));

Output:
Testorder of printing174,


greenhorn

 

[Alex Fraser]

From man pages in unix it seem the behavior in below usage of
printf() is undefined. But, is there something to be noted from the
output of the below line.

printf("%d %d", i = printf("order of printing"),j = printf("Test"));

Yes, you may deduce the behaviour of your implementation in these
circumstances. The behaviour may be different for other implementations
and/or in other circumstances.

Alex

 

[Walter Roberson]

: From man pages in unix it seem the behavior in below usage of
rintf() is undefined.

That depends on what you mean by 'undefined'. The order of processing
parameters for a function call is not mandated by the standard, but
it is mandated that the parameters be processed "as if by
assignment" before the routine itself is invoked.

The behaviour is thus just the usual behaviour in the presence of
side-effects: they can occur in any order, and in some instances
may occur varying numbers of times.

:But, is there something to be noted from the
utput of the below line.

: printf("%d %d", i = printf("order of printing"),j = printf("Test"));

:Output:
:Testorder of printing174,

Yes, one can learn that something is broken:
- The printf format has a space between the two %d's, but the output
shown does not
- There is no comma in the output formats, but there is one in
the output shown; it should not have occured


Other than that, one could tentative figure that the in the absence
of optimization reasons otherwise, parameters are probably processed
from right to left. There is correlation with right to left processing
and implimentations that push each parameter value onto a stack
before making the call -- as contrasted with implimentations that
allocate an amount of storage large enough to hold all the parameters
(their types are all known, so the total storage can be computed)
and then store the parameters at offsets from the beginning of the
block (which tend to use left-to-right calling so as to write the
parameter values into increasing storage with incrementing stack pointer.)
Push-onto-the stack implimentations are also correlated to
ABIs in which the stack grows upwards rather than downwards.

But all of these are tentative and usually of interest only when doing
implimentation-dependant (non-portable) interfacing with non-C routines.
Though one might want to know the direction the stack grows in order
to know whether the overall program memory layout is suitable...
which would depend upon the ABI.

 

[Flash Gordon]

Hi,
From man pages in unix it seem the behavior in below usage of
printf() is undefined.

The man page is, in this instance, entirely correct as far as the C
standard is concerned. So don't do it.

> But, is there something to be noted from the
output of the below line.

printf("%d %d", i = printf("order of printing"),j = printf("Test"));

Output:
Testorder of printing174,

Well, if you ran it on a Quarckle Froozit using it's native compiler
that information would tell you that it was exactly 4:52:13 on the 1st
July 79 BC, since that is the only time when it ever produces that
result (setting the clock on the machine is not sufficient, it actually
has to be that date/time in reality). Of course, the Quarckle Froozit
did not exist then, so this is entirely academic.

 

[Old Wolf]

The man page is, in this instance, entirely correct as far as the C
standard is concerned. So don't do it.

printf("Test"));

Actually, the behaviour is unspecified.

Assuming that printf succeeds, stdout must have received either:
Testorder of printing17 4
or
order of printingTest17 4

 

[pete]

The man page is, in this instance, entirely correct as far as the C
standard is concerned. So don't do it.


Well, if you ran it on a Quarckle Froozit using it's native compiler
that information would tell you that it was exactly 4:52:13 on the 1st
July 79 BC, since that is the only time when it ever produces that
result (setting the clock on the machine is not sufficient,
it actually
has to be that date/time in reality). Of course, the Quarckle Froozit
did not exist then, so this is entirely academic.

I'm not seeing it as undefined.
The order in which function arguments are evaluated is unspecified.

 

[Flash Gordon]

I'm not seeing it as undefined.
The order in which function arguments are evaluated is unspecified.

OK, I was wrong about undefined. However, Is it mandated that it always
evaluates them in the same order? Also, is it mandated that it does not
evaluate them in parallel (something that could, in theory, be done on
dual processor PCs)?

If the order does not always have to be the same what I said could still
be true ;-)

I still stand by don't do it.

 

[pete]

OK, I was wrong about undefined. However,
Is it mandated that it always
evaluates them in the same order?
No.

Also, is it mandated that it does not
evaluate them in parallel
(something that could, in theory, be done on
dual processor PCs)?

The arguments have function calls.
Function calls are sequence points
and can only take place one at a time.
The subsequent assignments to i and j, can take place in any order.

If the order does not always have to be the same
what I said could still be true ;-)

No.
There's a limit to the choices that the computer can make.
Undefined behavior is different.