Don't use Scanf()

Matthew Belmonte belmonte at svax.cs.cornell.edu
Thu Mar 17 23:54:38 AEST 1988


In article <46.bagpiper at oxy.UUCP> bagpiper at 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 at sleepy.cs.cornell.edu
BITNET:		belmonte at CRNLCS
*** The Knights of Batman ***
(Computer science 1, College 5, Johns Hopkins CTY Lancaster '87 session 1)



More information about the Comp.lang.c mailing list