[comp.lang.c] Compiler checking of printf

yuleat@prlhp1.prl.philips.co.uk (yuleat) (07/13/88)

Having used a reasonable variety of C compilers in the past few
years, I was somewhat surprised recently by a warning message I
received from the ANSI (yes, I know the standard isn't finished
yet) C compiler I have for my home computer (an Acorn Archimedes).
After a bit of testing, I found that not only would it issue a
warning if the wrong number of arguments were passed to printf(),
but it also checked that the types of the arguments matched the
specifiers in the format string.

Is this part of the standard? If not, is it a particularly novel
feature?
This behaviour implies to me, that the printf() command is broken
down by the compiler to produce (at least partly) in-line code,
is this likely/reasonable?

(As an aside, the compiler is very good value for c. 100 quid.
 My thanks to messers Mycroft & Norman - the authors)

chris@mimsy.UUCP (Chris Torek) (07/15/88)

In article <524@prlhp1.prl.philips.co.uk> yuleat@prlhp1.prl.philips.co.uk
(yuleat) writes:
>After a bit of testing, I found that not only would [the new compiler]
>issue a warning if the wrong number of arguments were passed to printf(),
>but it also checked that the types of the arguments matched the
>specifiers in the format string.

>Is this part of the standard?

Yes; or rather, the dpANS *permits* this action.  It does not *require*
it.  A good compiler will do its best to check.

>This behaviour implies to me, that the printf() command is broken
>down by the compiler to produce (at least partly) in-line code,
>is this likely/reasonable?

Possibly so.  In the worst case a full-blown printf() interpreter
is still necessary, so as to handle code such as

	char *fmt = make_up_some_format();
	...
	(void) printf(fmt, arg1, arg2, arg3);

In the best case, converting statements like

	(void) printf("\tfoo\t%s,%s\n", a, b);

to ones like

	(void) (fputs("\tfoo\t", stdout),
	 fputs(a, stdout), putchar(','), fputs(b, stdout),
	 putchar('\n'));

can gain quite a bit of speed in the resulting executable.  (Doing
it by hand made a nice difference in the latest 4BSD PCC C compiler.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris