printf() problem

Chris I'm Outta Here! Seaman crs at cpsc6b.cpsc6a.att.com
Fri Apr 28 03:48:57 AEST 1989


zougas at me.utoronto.ca ("Athanasios(Tom) Zougas") writes:
< jdm at 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 at cpsc6a.att.com <or> |      ||         See "Attack of the Killer Smiley"!
..!ihnp4!cpsc6a!crs     |   \vvvvvv/     Coming Soon to a newsgroup near you!
                        |    \____/ 



More information about the Comp.lang.c mailing list