Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!umd5!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.lang.c Subject: Re: Compiler checking of printf() Keywords: ANSI standard, printf() Message-ID: <12491@mimsy.UUCP> Date: 15 Jul 88 03:10:37 GMT References: <524@prlhp1.prl.philips.co.uk> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 37 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