Xref: utzoo comp.sys.m6809:727 comp.lang.c:8259 Path: utzoo!mnetor!uunet!husc6!bbn!rochester!cornell!svax!belmonte From: belmonte@svax.cs.cornell.edu (Matthew Belmonte) Newsgroups: comp.sys.m6809,comp.lang.c Subject: Re: Don't use Scanf() Message-ID: <2071@svax.cs.cornell.edu> Date: 17 Mar 88 13:54:38 GMT References: <46.bagpiper@oxy.UUCP> Reply-To: belmonte@sleepy.cs.cornell.edu (Matthew Belmonte) Followup-To: comp.sys.m6809 Organization: Cornell Univ. CS Dept. Lines: 42 Summary: including printf argument semantics In article <46.bagpiper@oxy.UUCP> bagpiper@oxy.uucp writes: [on the subject of printf and puts, and all the other library goodies:] >These are not part of the language!! They are some external routine. The >compiler can`t do this kind of optimization. Well, not exactly. It is possible to get the compiler to do such an optimisation; it wouldn't be hard. Consider the following snatch of an attribute grammar: expr ::= ident '(' args ')' { . . /*there is a lot of code here that does other things*/ . . /*now, here's the part where we're about to emit a symbol for the printf call:*/ fprintf(outfile, "lbsr %s /*call the subroutine*/\n", $3.is_const && TypesEqual($3.type, STRING) ? "_puts" : "_printf"); . . . } ; args ::= args arg { . . /*there's code here to shove the argument onto the stack*/ $$.is_const = false; } | arg { $$.is_const = $1.is_const; $$.type = $1.type; } ; The .type and .is_const attributes are propagated up from the expressions which constitute the arguments. So, it wouldn't be much of a job to hack something like this in, if you were given the source for an existing C compiler. BUT... Mods like this can be more of a pain in the ass than they are a help. Here the programmer has no control over what library routines will end up included in his object. This compiler is fickle, and that's BAD. -- Matthew Belmonte Internet: belmonte@sleepy.cs.cornell.edu BITNET: belmonte@CRNLCS *** The Knights of Batman *** (Computer science 1, College 5, Johns Hopkins CTY Lancaster '87 session 1)