Don't use Scanf()

[Karl Heuer]

[ The previous article was directed to comp.sys.m6809, but this is a language
issue.  I'm redirecting back to comp.lang.c.  --kwzh ]

In article <2108 at svax.cs.cornell.edu> belmonte at sleepy.cs.cornell.edu (Matthew Belmonte) writes:
>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.

I don't see that such a compiler would have to depend on the implementation;
just on the functional specification (which has now been standardized).  Thus,
it's quite safe for a compiler to convert, say, "memcpy" into a block-copy
instruction.  (But a safer approach is to recognize "__builtin_memcpy"
instead, and place "#define memcpy(x,y,z) __builtin_memcpy(x,y,z)" into the
appropriate header file.)

Btw, "never" is too strong.  Some C compilers already do this inlining.  With
the upcoming standard, it will probably become more popular.

Karl W. Z. Heuer (ima!haddock!karl or karl at haddock.isc.com), The Walking Lint