Ben Bacarisse
6/23/2011 11:58:00 AM
James Waldby <not@valid.invalid> writes:
> On Wed, 22 Jun 2011 15:55:48 -0600, Joe Pfeiffer wrote:
>
>> PRADEEP <nospam@nospam.com> writes:
> ...
>>> 2)
>>> #include<conio.h>
>>> #include<stdio.h>
>>> void main()
>>> {
>>> int i=9;
>>> printf("%d %d %d %d",i++,++i,i--,--i); getch();>>
>>> }
>>>
>>> output
>>>
>>> 9 9 8 8
>>>
>>> I want to know how came this o/p ,when one would obviously expect the
>>> o/p to be 9 11 11 9. [...]
>>
>> The parameters are evaluated and pushed on the stack right-to-left, so
>> the result is exactly what should be expected.
>>
>> Note -- I don't think this behavior is actually guaranteed (so another
>> implementation could give the results you were expecting). Even if it
>> is, coding like that isn't something to which you want to subject some
>> later reader of your code.
>
> Right, 6.5.2.2p10 (in N1256 draft) says, "The order of evaluation of the
> function designator, the actual arguments, and subexpressions within the
> actual arguments is unspecified, but there is a sequence point before
> the actual call." 6.5.2.2p12 says, "EXAMPLE In the function call
> (*pf[f1()]) (f2(), f3() + f4()) the functions f1, f2, f3, and f4 may
> be called in any order. All side effects have to be completed before
> the function pointed to by pf[f1()] is called."
Reading only this, one might think that all the possible outcomes could
be enumerated simply by considering all the different ordering for
evaluating the function's arguments, or that one need only consider the
order in which the side effects happen, but it's worse than that: 6.5 p2
makes the behaviour undefined.
It's possible that this UB will be exploited in the future in more and
more unpredictable ways. As memory hardware becomes more and more
sophisticated, who's to say what will happen when multiple un-sequenced
updates are scheduled?
--
Ben.