Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!rutgers!cmcl2!lanl!jlg
From: jlg@lanl.gov (Jim Giles)
Newsgroups: comp.lang.c
Subject: Re: ambiguous ?
Message-ID: <14089@lanl.gov>
Date: 16 Oct 89 20:28:08 GMT
References: <11312@smoke.BRL.MIL>
Organization: Los Alamos National Laboratory
Lines: 27

From article <11312@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn):
> In article <20974@gryphon.COM> bagpiper@pnet02.gryphon.com (Michael Hunter) writes:
>>In the following code fragment is line 3 ambiguous from an X3J11 standpoint
>>or from a historical standpoint.
>>3) func(Ret = func2(), Ret+30) ;
> 
> Both, because the order in which function arguments are evaluated has
> always been implementation-dependent.  [...]
  ^^^^^^

Maybe that's what it has "always" been - but the ANSI standard says
different.  The ANSI standard has three different categories for
'ambiguous' constructs: 1) _Unspecified_ - the standard imposes no
requirements at all; 2) _Undefined_ - The construct is illegal or
non-portable, the standard imposes no requirements; 3) _Implementation_
_defined_ - the behaviour is determined by the implementation.

The order of evaluation of function arguments is _Unspecified_ not
_Implementation_defined_.  This means that the evaluation order is
allowed to vary EVEN WITHIN AN IMPLEMENTATION!  This is supposedly
to allow optimization.

It is my opinion that _Unspecified_ and _Undefined_ have no place in
a language definition.  _Implementation_defined_ should be used as little
as possible.  Apparently, X3J11 thought otherwise (this makes C the only
ANSI language with deliberately undefined, as opposed to implementation
defined, behaviour).