ambiguous ?

Jim Giles jlg at lanl.gov
Tue Oct 17 06:28:08 AEST 1989


>From article <11312 at smoke.BRL.MIL>, by gwyn at smoke.BRL.MIL (Doug Gwyn):
> In article <20974 at gryphon.COM> bagpiper at 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).



More information about the Comp.lang.c mailing list