Compiler checking of printf()

[Chris Torek]

In article <524 at prlhp1.prl.philips.co.uk> yuleat at 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 at mimsy.umd.edu	Path:	uunet!mimsy!chris