Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!uxm.sm.ucl.ac.UK!andrew
From: andrew@uxm.sm.ucl.ac.UK (Andrew Dawson)
Newsgroups: comp.sys.atari.st
Subject: Re: A Lesson Learned
Message-ID: <8903301056.AA29338@uk.ac.ucl.sm.uxm>
Date: 30 Mar 89 09:56:02 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 34

In issue 106, Charles S. [Chip] Roberson <csrobe@icase.edu>, writes:

(extracts only quoted below)
> Below is a pretty slick fprintf() statement from some of the UUPC/ST code
> I was sure that it should work. It's pretty straight forward -- pass
> fprintf() 3 arguments: stderr, the appropriate format string, and finally
> the desired value to print.  Then once the value is passed, increment.
>	fprintf( stderr, isprint(*cp)? "[%c]":"[%02x]", *cp++ );
> MWC passes parameters in reverse order.  That means that the "*cp++"
> gets evaluated BEFORE the "isprint(*cp)..." stuff .....
> .... How do other ST compiler's pass their parameters?  So much for
> portability... Does anybody know how the dpANS standard would affect this,
> if at all?  I can't seem to remember anything in it that would.

K&R 2nd edition states:
"The order in which function arguments are evaluated is not specified,
so the statement
    printf("%d %d\n", ++n, power(2,n));    /* WRONG */
can produce different results with different compilers, depending on
whether n is incremented before power is called. The solution is to
write
    ++n;
    printf("%d %d\n", n, power(2,n));      "

Most compilers I've used on the ST seem to evaluate right to left.
Note in particular, that the system interfaces gemdos/bios/xbios
expect to receive parameters this way, so any compiler that works the
other way would have to incorporate argument reversing code for these
functions.


Andrew Dawson
School of Medicine Computer Unit
University College London