Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uupsi!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: Function Argument Evaluation
Message-ID: <15591@smoke.brl.mil>
Date: 26 Mar 91 22:50:58 GMT
References: <17809@crdgw1.crd.ge.com> <15552@smoke.brl.mil> <17882@crdgw1.crd.ge.com>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 20

In article <17882@crdgw1.crd.ge.com> volpe@camelback.crd.ge.com (Christopher R Volpe) writes:
-In article <15552@smoke.brl.mil>, gwyn@smoke.brl.mil (Doug Gwyn) writes:
-|>In article <17809@crdgw1.crd.ge.com> volpe@camelback.crd.ge.com (Christopher R Volpe) writes:
-|>>Ok, but I believe that is true only because the behavior is undefined
-|>No; the order of evaluation in this example is explicitly UNSPECIFIED,
-Oh, by the way, Doug, I didn't say the order of evaluation was undefined.
-I said the behavior of the program itself was undefined (as Colin
-pointed out). And I'm not saying it's because of any unspecified order
-of evaluation. It's because the object referenced by p has its value 
-modified more than once between sequence points. (Is this right?)

Sorry, but I cannot make sense out of your use of these terms.  They have
precise meanings in the context of the C standard, and they have an effect
of standard conformance, all explained in Section 1 of the ANSI C standard.

-Is it true that the behavior of the program is undefined (for the above
-reason)?

No, but the output depends on some unspecified aspects of the implementation.
I've already explained why, to the best of my ability.