Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!udel!haven!adm!smoke!gwyn From: gwyn@smoke.brl.mil (Doug Gwyn) Newsgroups: comp.std.c Subject: Re: More Re: Function Argument Evaluation argument Message-ID: <15678@smoke.brl.mil> Date: 2 Apr 91 22:24:56 GMT References: <15607@smoke.brl.mil> <18140@crdgw1.crd.ge.com> Organization: U.S. Army Ballistic Research Laboratory, APG, MD. Lines: 24 In article <18140@crdgw1.crd.ge.com> volpe@camelback.crd.ge.com (Christopher R Volpe) writes: >|> printf("%d %d\n", (1, v), (1,v++)); >Hey, that looks pretty good. No matter what the order of evaluation of >the function arguments is, there's always a sequence point separating the >references to v. So the behavior is not undefined, yet order of evaluation >definitely has a drastic effect on the output. >Anybody see a problem with that? Yes, perhaps the order of evaluation of the subexpressions is still unspecified even though one might think that there are sequence points involved. The question is whether the sequence-point constraints bind more tightly than the unspecified-order specification or more loosely. A similar issue arose with regard to the first formal request for interpretation of X3.159, only in that case the sloppy-order specification was the one permitted for assignment expressions. In the case of that interpretation, X3J11 finally (at the March 1991 meeting) decided that the 3.3.16.1 license did NOT override the expectation that the function value had to be "copied" out. If that is taken as a precedent, then a consistent interpretation for the above example ought to be that the sequence point ordering is more important than the argument subexpression evaluation ordering license. However, without a formal interpretation ruling I would hesitate to promise that it "must" be that way. Certainly, nobody should write code like that!