Orphaned Response - (nf)

[mike at smu.UUCP]

#R:elecvax:-20400:smu:21700002:37777777600:1745
smu!mike    Aug  4 17:40:00 1984

Written with regard to:

/**** smu:net.bugs / mtxinu!ed /  8:32 am  May 30, 1984 ****/
If you change the behaviour of the preprocessor, remember that
C requires that the order of evaluation of expressions be
undefined.  Therefore, depending on any evaluation order
will yield unportable code.

-- 
Ed Gould
ucbvax!mtxinu!ed
/* ---------- */

>From whence comes the notion that the order of evaluation of
expressions is undefined?  Surely most expression which appear in most
programs assume some order of evaluation, as well they should.  The
expression

	x = (y + z) * 10

should be evaluated in the same order that any high-school algebra
student would assume.  If the C language did not define the order
of evaluation for the above, would it not be difficult to get any
programs working?  Order of evaluation is only undefined where some
algebraic rules can be applied to re-arrange an expression without
changing the implied sense of the expression.

I am not really sure how order of expression evaluation relates to
cpp anyway.  Anything cpp does is done before expression evaluation is
even begun.

In regards to the original note (about evaluation of macro arguments
by cpp), I think that the problem presented relates to the question of
how macro expansion can be selectively enabled (or, in the case of
cpp, disabled).  The macro language m4, along with most other macro
languages of its ilk which I have seen, provide for either an explicit
expansion inhibitor or an explicit expansion enabler.  Given this, the
programmer would have somewhat more power in the application of cpp
macros.  I imagine that this question has been addressed before and
that some excuse was made for the limitations of cpp.

Mike McNally
...convex!smu!mike