Re^2: Don't use Scanf()

[Ray Dunn]

In article <3850011 at hpfclq.HP.COM> mike at hpfclq.HP.COM (Mike McNelly) writes:

I write:
.Compilers do not have the ability to understand the functionality of the
.procedures being called and alter the code (and arguments!) accordingly!

[someone] writes (I did not see the posting):
.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.
.etc.....

Mike writes:
.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.

I don't think that *one* aspect has been missed.  My whole point has been
missed by [unknown] as clearly stated by Mike above.

In *'C'* the compiler does *not* know what the definition of printf etc is.

Yes, the meaning of printf *could* be restricted to some pre-defined value,
the compiler *could* be given such information, or it *could* do a library
search at compile time, the language *could* be defined so that general user
defined procedures calls could be replaced with optimized in-line code, etc,
etc.

The generalizations made above by [unknown] are indeed possible, but aren't
we discussing 'C' or at best 'D', which we hope would be of the same family?

Ray Dunn.  ..{philabs,mnetor)!micomvax!ray