Xref: utzoo comp.sys.m6809:747 comp.lang.c:8740
Path: utzoo!utgpu!water!watmath!clyde!ima!haddock!karl
From: karl@haddock.ISC.COM (Karl Heuer)
Newsgroups: comp.sys.m6809,comp.lang.c
Subject: Re: Don't use Scanf()
Keywords: C stdio library
Message-ID: <3266@haddock.ISC.COM>
Date: 31 Mar 88 18:30:25 GMT
References: <2401@ihwpt.ATT.COM> <320@c10sd1.StPaul.NCR.COM> <1185@ucsfcca.ucsf.edu> <9241@sunybcs.UUCP> <960@micomvax.UUCP> <2108@svax.cs.cornell.edu>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Followup-To: comp.lang.c
Organization: Interactive Systems, Boston
Lines: 22

[ 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@svax.cs.cornell.edu> belmonte@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@haddock.isc.com), The Walking Lint