Path: utzoo!attcan!uunet!mitel!sce!scs!spl1!gargoyle!tank!eecae!mailrus!tut.cis.ohio-state.edu!quanta.eng.ohio-state.edu!kaa.eng.ohio-state.edu!rob
From: rob@kaa.eng.ohio-state.edu (Rob Carriere)
Newsgroups: comp.sys.atari.st
Subject: Re: A Lesson Learned
Message-ID: <1761@quanta.eng.ohio-state.edu>
Date: 20 Mar 89 23:00:11 GMT
References: <8903202254.AA00303@icase.edu>
Sender: news@quanta.eng.ohio-state.edu
Reply-To: rob@kaa.eng.ohio-state.edu (Rob Carriere)
Organization: Ohio State Univ, College of Engineering
Lines: 26

In article <8903202254.AA00303@icase.edu> csrobe@ICASE.EDU 
(Charles S. [Chip] Roberson) writes:
[...]
>	fprintf( stderr, isprint(*cp)? "[%c]":"[%02x]", *cp++ );
[doesn't work]
>The moral of this story?  Well, as my Theory of Prog. Lang prof would
>say, "That's just another insecurity of C!"; to which he would add
>"Ada is a much better language."  Well, I guess I would say
>"Hey! Be careful out there."

He may say that, but it'd be false.  Order of parameter evaluation is
*undefined* in both C and ADA.  In other words, can do in ADA, no prob!

The *real* moral of the story is:  Thou shalst not rely on the order
in which side-effects in the parameters thou art passing to thy
function shall take place, for that order hath not been standardized. 

>Seriously, this is one side-effect that I hadn't thought about.  How
>do other ST compiler's pass their parameters?  So much for portability,
>eh?  Does anybody know how the dpANS standard would affect this, if at
>all?  I can't seem to remember anything in it that would.

No, twon't.  No problem though, just say no to side-effects in
function arguments.

SR