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