Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!pprg.unm.edu!hc!lll-winken!uunet!snjsn1!bilbo!greg
From: greg@bilbo (Greg Wageman)
Newsgroups: comp.sys.atari.st
Subject: Re: A Lesson Learned
Summary: RTFM!
Message-ID: <768@snjsn1.SJ.ATE.SLB.COM>
Date: 23 Mar 89 16:35:20 GMT
References: <8903202254.AA00303@icase.edu>
Sender: news@SJ.ATE.SLB.COM
Reply-To: greg@sj.ate.slb.com (Greg Wageman)
Organization: Schlumberger ATE, San Jose, CA
Lines: 49

In article <8903202254.AA00303@icase.edu> csrobe@ICASE.EDU (Charles S. [Chip] Roberson) writes:
>Greetings fellow psycho-programmers!  Well, I just learned a lesson today
>and I thought I pass it on to any others who haven't learned this, yet.
>It only blew a day and a half of my time.
>
>	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.  So, everytime
>fprintf will get passed the approprate character, but isprint is going
>to look at whatever is in the next data location.  [In my case that was
>usually garbage in an unused portion of a character buffer!]
>
>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.

"The C Programming Language", Kernighan & Ritchie, Second Edition,
page 53, reproduced verbatim:

	"Similarly, 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, of course, is to write

		++n;
		printf("%d %d\n", n, power(2, n));"

It's a shame you wasted so much time on a well-documented aspect of
the C language.  I guess you didn't RTFM. :-)

What gets *me* ticked off is when I *do* RTFM, and TFM is *wrong*.


Longish .signature follows.  Skip now, or don't complain!

Greg Wageman			DOMAIN: greg@sj.ate.slb.com
Schlumberger Technologies	UUCP:   ...!uunet!sjsca4!greg
1601 Technology Drive		BIX:    gwage
San Jose, CA 95110-1397		CIS:    74016,352
(408) 437-5198			GEnie:  G.WAGEMAN
------------------
Opinions expressed herein are solely the responsibility of the author.
(And the author wouldn't have it any other way.)