Prev: Error :: compile serilization program given in boost library examples
Next: Available C++ Libraries FAQ
From: Anubhav on 1 May 2010 21:59 void f(int, int){} int main(){ int i = 0; // L1 f(i++, i++); // L2 } As per my understanding the order of evaluation of function call arguments is unspecified. In this code, there is a sequence point at the ';' on L1 and a sequence point at the entry of the function 'f'. In between these sequence points, the scalar 'i' is modified twice and this is the recipe for 'undefined behavior' Therefore we have both the forces playing here 'unspecified behavior' and 'undefined behavior'? So what do we conclude. Does the function call 'f(i++, i++)' have undefined behavior or 'unspecified behavior'? Regards, Dabs. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Johannes Schaub (litb) on 2 May 2010 01:26
Anubhav wrote: > void f(int, int){} > > int main(){ > int i = 0; // L1 > f(i++, i++); // L2 > } > > As per my understanding the order of evaluation of function call > arguments is unspecified. In this code, there is a sequence point at > the ';' on L1 and a sequence point at the entry of the function 'f'. > In between these sequence points, the scalar 'i' is modified twice and > this is the recipe for 'undefined behavior' > > Therefore we have both the forces playing here 'unspecified behavior' > and 'undefined behavior'? > > So what do we conclude. Does the function call 'f(i++, i++)' have > undefined behavior or 'unspecified behavior'? > Any program exhibiting undefined behavior has undefined behavior. Whether it also contains undefined or implementation defined behavior isn't important anymore then. You don't even have to hit the undefined behavior at execution. Just having the mere possibility to hit it by unspecified behavior is enough for the standard to place no requirements on an implementation. In your case, the undefined behavior will always be hit. But consider: int main() { int *p = 0; int a, b; if(&a < &b) a = *p; } That program has "effectively" undefined behavior because the value of "&a < &b" is unspecified. Thus whether the UB of derferencing the null pointer is hit or not is not determined. Thus the undefinednes of the behavior is not determined, and the standard places no requirements on an implementation executing that program. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |