Path: utzoo!attcan!uunet!lll-winken!ames!amdahl!rtech!cpsc6a!cpsc6b!crs
From: crs@cpsc6b.cpsc6a.att.com (Chris (I'm Outta Here!) Seaman)
Newsgroups: comp.lang.c
Subject: Re: printf() problem
Keywords: C printf
Message-ID: <518@cpsc6b.cpsc6a.att.com>
Date: 27 Apr 89 17:48:57 GMT
References: <11657@hodge.UUCP> <89Apr26.092233edt.18850@me.utoronto.ca>
Organization: AT&T (CPSC), Oakland, CA
Lines: 40

zougas@me.utoronto.ca ("Athanasios(Tom) Zougas") writes:
< jdm@hodge.UUCP (jdm) writes:
< >    Perhaps someone could explain this printf() phenomena to me.

[printf example deleted...]

< C puts its function parameters on the stack in "reverse" order, i.e.
< the last item is on top (this allows variable number of parameters
< for user defined functions). Thus, the last item is accessed FIRST. So
< what is happening is the last getc(fp) is called first and hence the
< reversal.

Actually, this is not quite true.  Since there is no specification in
ANSI or K&R regarding the order of evaluation of arguments to a function,
the actual processing is compiler dependent.  Some will evaluate in a
last in, first out (LIFO) order, and some in a FIFO order.  You have
no guarantees, though.

< What you did will correct it. Or try:
< 
< 	for ( i = 0; i < 4; ++i ) {
< 	    printf( "%x ", getc(fp) );
< 	}
< 	printf( "\n" );
< 
< Of course, where you are gaining in not having to declare 4 variables,
< you are losing in 5 calls of printf. Trade-offs, trade-offs ...

I hope this doesn't start a flame war, but IMHO, you should NEVER use
a function with all the overhead of printf() to output a simple linefeed.
putchar() or fputc() would do the same job, without all the overhead.

< Tom.
< 

-- 
Chris Seaman            |    o\  /o
crs@cpsc6a.att.com <or> |      ||         See "Attack of the Killer Smiley"!
..!ihnp4!cpsc6a!crs     |   \vvvvvv/     Coming Soon to a newsgroup near you!
                        |    \____/