Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > evaluation of arguments to a function

Reply
Thread Tools

evaluation of arguments to a function

 
 
Greenhorn
Guest
Posts: n/a
 
      03-04-2005
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

 
Reply With Quote
 
 
 
 
Alex Fraser
Guest
Posts: n/a
 
      03-04-2005
"Greenhorn" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com...
> 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


 
Reply With Quote
 
 
 
 
Walter Roberson
Guest
Posts: n/a
 
      03-04-2005
In article <(E-Mail Removed) .com>,
Greenhorn <(E-Mail Removed)> wrote:
: 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.
--
Positrons can be described as electrons traveling backwards in time.
Certainly many Usenet arguments about the past become clearer when they
are re-interpreted as uncertainty about the future.
-- Walter Roberson
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      03-04-2005
Greenhorn wrote:
> 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.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
 
Reply With Quote
 
Old Wolf
Guest
Posts: n/a
 
      03-04-2005
Flash Gordon wrote:
> Greenhorn wrote:
> > 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"));

Actually, the behaviour is unspecified.

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

 
Reply With Quote
 
pete
Guest
Posts: n/a
 
      03-04-2005
Flash Gordon wrote:
>
> Greenhorn wrote:
> > 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.


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

--
pete
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      03-04-2005
pete wrote:
> Flash Gordon wrote:
>
>>Greenhorn wrote:
>>
>>>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.

>
> 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.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
 
Reply With Quote
 
pete
Guest
Posts: n/a
 
      03-04-2005
Flash Gordon wrote:
>
> pete wrote:
> > Flash Gordon wrote:
> >
> >>Greenhorn wrote:
> >>
> >>>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.

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


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.

--
pete
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Proposal for lazy evaluation of C++ function arguments clintonmead@gmail.com C++ 2 11-14-2012 01:52 PM
how to pass a function name and its arguments inside the arguments of other function? jmborr Python 1 11-03-2007 08:20 AM
Order of evaluation of function arguments dragoncoder C Programming 21 12-23-2005 07:08 PM
[EVALUATION] - E03 - jamLang Evaluation Case Applied to Python Ilias Lazaridis Python 2 04-24-2005 05:29 PM
[EVALUATION] - E03 - jamLang Evaluation Case Applied to Ruby Ilias Lazaridis Ruby 74 04-04-2005 05:29 PM



Advertisments