Re^2: Don't use Scanf()

[Mike McNelly]

> In article <960 at micomvax.UUCP> ray at micomvax.UUCP (Ray Dunn) writes:>
> >Compilers do not have the ability to understand the functionality of the
> >procedures being called and alter the code (and arguments!) accordingly!

> What you mean to express by "understand the functionality" appears nebulous to
> me.  As I said before, nothing practical prevents one from including the
> semantics of standard functions in compilers.  Conversions from one sequence of
> statements to another with equivalent semantics can be expressed using
> attribute grammars.

> >Apart from anything else, the "functionality" of printf and puts is only
> >determined at *link* time!

> Again, it is unclear to me what you mean by determination of "functionality."
> It is true that in a typical compiler, the only optimisations done are
> flow-of-control optimisations (e.g. induction variables reduction in strength,
> live variable analysis, code motion) and computation and storage optimisations
> (e.g. elimination of common subexpressions, copy propagation, constant folding,
> register allocation) *within* the code being compiled.  Calls to external
> functions  can be treated atomically, as "black boxes" -- but there's no rule
> that says they *have* to be.  If a function is part of a standard library, then
> rules can be included in the compiler for simplification of those functional
> expressions.

> To take a simple example, suppose I have a standard function called expt which
> takes a floating-point argument and raises it to a power.  Suppose I have a
> functional expression "expt(x, 2)".  So rather than calling in my high-powered
> expt function it would be much simpler to do a floating-point multiply of x*x.
> This is a reduction in strength which encompasses an invocation of a standard
> function.  (Suppose I had an exponentiation operator "**" s.t. "x ** y" gives
> the value of expt(x, y).  Then there would be no external function involved,
> and everything would be straightforward.)

> So *why* do we never see semantics of standard functions included in compilers?
> Because, in my opinion, it's not worth it.  It makes the compiler dependent on
> the standard libraries.  If my compiler's rules assume a particular
> implementation of a standard function, then if I change the implementation I'm
> liable to have either to change the compiler or to live with inefficient code.

> In summary:  There is no inherent limitation of compilers which prevents their
> knowing about standard functions.  Despite this, we never see compilers playing
> with standard functions, because that would create too much of a tangled mess
> of dependencies.  So Fai Lau was being unrealistic in saying that compilers
> which don't do this sort of thing are unimaginable.  Yet at the same time, it
> is wrong to assert, as Ray Dunn does, that such optimisations are impossible.

> Comments are welcome.

I think that one aspect has been missed.  True, the compiler can
certainly understand the semantics of a routine such as printf() or
sin() or whatever, most easily if the routine is within that file.
However, there's no guarantee that the programmer doesn't have his own
version of these routines that is intended to be linked into the a.out.
Unless you reserve these names as part of the language (not C) or
provide some disambiguating construct (again not C) it's not possible to
determine the programmer's intent until link time.

Mike McNelly
hplabs!hpfcla!mike