Newsgroups: comp.lang.c
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: ambiguous ?
Message-ID: <1989Oct17.203733.23121@utzoo.uucp>
Organization: U of Toronto Zoology
References: <11312@smoke.BRL.MIL> <14089@lanl.gov>
Date: Tue, 17 Oct 89 20:37:33 GMT

In article <14089@lanl.gov> jlg@lanl.gov (Jim Giles) writes:
>... 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.

A more accurate definition of _implementation_ _defined_ is that the
behavior is determined by the implementation *and must be documented*.
Otherwise it doesn't differ from _unspecified_ in any useful way.

>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.

Yup.  Which it does.  (For example, in an argument list with expressions
of varying complexity, on a machine with few registers that wants to pass
arguments in registers, it is best to evaluate the complicated arguments
first so that the maximum number of registers are available for the job.)
This is the same, for much the same reasons, as letting subexpressions
of a single expression be evaluated in arbitrary order.  What's wrong
with it?

>... (this makes C the only
>ANSI language with deliberately undefined, as opposed to implementation
>defined, behaviour).

I could have sworn that a good many things were officially undefined in
Fortran (66 or 77, take your pick), such as the values of local variables
after return from a function.  I could be wrong -- I'm not a Fortran guru.
-- 
A bit of tolerance is worth a  |     Henry Spencer at U of Toronto Zoology
megabyte of flaming.           | uunet!attcan!utzoo!henry henry@zoo.toronto.edu