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