Evaluating autoincrements in function calls

[mcvoy at uwvax.UUCP]

In article <5604 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
-In article <3279 at 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 at rsch.wisc.edu, 
      		        {seismo, topaz, harvard, ihnp4}!uwvax!mcvoy

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