Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!uwvax!mcvoy
From: mcvoy@uwvax.UUCP
Newsgroups: comp.unix.questions
Subject: Re: Evaluating autoincrements in function calls
Message-ID: <3285@rsch.WISC.EDU>
Date: Fri, 27-Feb-87 17:57:34 EST
Article-I.D.: rsch.3285
Posted: Fri Feb 27 17:57:34 1987
Date-Received: Sun, 1-Mar-87 10:19:24 EST
References: <4707@brl-adm.ARPA> <3279@rsch.WISC.EDU> <5604@mimsy.UUCP>
Reply-To: mcvoy@rsch.WISC.EDU (Lawrence W. McVoy)
Organization: U of Wisconsin CS Dept
Lines: 35

In article <5604@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
-In article <3279@rsch.WISC.EDU> I write:
->It is unfortunate, though.  Inconsistencies suck.
-
-What inconsistencies?  Those between different compilers?  One must
-expect some.  

Well, correct me if I am wrong, but there is nothing inherent in the
language that _forces_ function argument evaluation to have an undefined
order.  One _could_ state that it works left-to-right or odd numbered args
first, then even, whatever.  It's just more work for the compiler writer
and potentially more code at procedure call time.  I've never written a
production compiler but I have studied them and written toy ones and I
think that I could evaluate args in any order you wish.

Don't get me wrong, I'm not arguing that we should change it, I'm just
trying to point out that it IS an inconsistency and that IS annoying.  If
you don't believe that, consider the result if they had decided that
operator precedence should be undefined as well (no, not the order of A +
B + C, but the order of A + B * 3 / 4).  They could have done this, right?
As long as they provided parens to force one way or another.  But it would
have certainly violated the rule of least astonishment, as does the
function arg stuff...

Actually, it's more than annoying, it causes non-portable code.  C hackers
being what they are tend not to worry about this until it bites them
(yeah, I know that _you_ worry about it, but you are the exception, not
the norm, I'm afraid).  If you don't believe that, try porting BSD code to
a 16 bit int machine or a machine that does make *((char*)0) == 0.  Have
fun :-)
-- 
Larry McVoy 	        mcvoy@rsch.wisc.edu, 
      		        {seismo, topaz, harvard, ihnp4}!uwvax!mcvoy

"It's a joke, son! I say, I say, a Joke!!"  --Foghorn Leghorn