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