strcpy wars, jeez! A proposed resolution.

[Michael Meissner]

In article <17 at feedme.UUCP> doug at feedme.UUCP (Doug Salot) writes:
| Both of these passages seem to imply that C compilers "know" about
| the semantics of certain (all?) function calls.  While someone earlier
| pointed out that it is possible to design a language in which some semantics 
| can be described, C does not have this facility and seems to be
| philosphically antagonistic to such a facility.  I would indeed be
| surprised if a C compiler produced inline code for strcpy (unless you
| are talking about a macro, in which case the behavior of the code should
| be clear from reading the define), and the idea of compile-time
| warnings about function behavior seems equally out of place (maybe
| link-time would be appropriate).

The DG C compiler for one will generate inline code for strcpy if the
second argument is a string literal, providing you include the standard
header <string.h> (and now <strings.h> as well).  I believe the
Microsoft 5.0 C compiler does similar things (possibly the DEC compiler
too).  Just because nobody upgrades the typical UNIX compiler, it
doesn't mean that it's true for all C compilers.  The way it is
implemented, there is a keyword ($builtin) that the standard header
files use where appropriate.  Users in general, don't have change the
code to get inline behavior, just use the standard header files.  Also,
for all builtin's, there is a module in the library, and taking the
address of a builtin, takes the address of the library routine.
-- 
Michael Meissner, Data General.		Uucp: ...!mcnc!rti!xyzzy!meissner
					Arpa/Csnet:  meissner at dg-rtp.DG.COM