strcpy wars, jeez! A proposed resolution.

[Doug Salot]

There's seems to be a point here with which both posters' agree, but I find
absurd.  For background:

nevin says:
> >If this were to change (something which I am against), all programs that
> >use strcpy() would be suspect every time a new version of the compiler
> >comes out (especially since many compilers use inline assembly instead of
> >doing a function call for strcpy()).  This is not something which should
> >depend on the implementation.

and david says:
> Of course, it would only be an issue for you to the extent that you need
> to work with (or in spite of!) these constructs that you seem
> disinclined to use anyway.  (Also, if you are sufficiently fortunate to
> use a compiler that has a mode in which it flags all constructs whose
> behavior is "implementation-defined," you can have that much more
> warning about such concerns.)

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).

As long as I'm here, I must say that I disagree with david.  If the
behavior of a function is *undefined* rather than *implementation
defined* for singular cases, one would be inclined not to use the
function for the singular cases, thereby insuring (used loosely)
portability.

- Doug
-- 
Doug Salot || doug at feedme.UUCP || {trwrb,hplabs}!felix!dhw68k!feedme!doug
Feedme Microsystems:Inventors of the Snarf->Grok->Munge Development Cycle