Path: utzoo!mnetor!uunet!husc6!cmcl2!nrl-cmf!ames!lll-tis!mordor!sri-spam!sri-unix!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: strcpy
Message-ID: <836@cresswell.quintus.UUCP>
Date: 30 Mar 88 07:49:22 GMT
References: <793@cresswell.quintus.UUCP> <545@anuck.UUCP> <4190@ihlpf.ATT.COM>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 22

In article <4190@ihlpf.ATT.COM>, nevin1@ihlpf.ATT.COM (00704a-Liber) writes:
> In article <810@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
> >>   The moral of this is, don't depend on bizarre side effects unless
> >The order in which strcpy works is hardly a "bizarre side effect".
> I'm sorry, but it is!

Questions like "what happens to the rest of the destination" and "what
happens if the two areas overlap" are so important that the answers
SHOULD be part of the description of strcpy(). It is extremely useful to
have a function which can safely be used to move part of a character
array towards its origin.  Given that strcpy() is the only possible
candidate for this in the SVID, that the description in the SVID can be
naturally construed as describing a left to right copy, and that the
descriptions of the string operations are pretty vague, it is reasonable
for someone to expect that strcpy() will work this way.

If the memcpy() question was solved by adding a memmove(), is there
also a strmove() in the current dpANS draft?

Does anyone know whether the vagueness of the SVID description of
strcpy() was intentional, or whether strcpy() was originally intended
to work left-to-right and the vagueness was accidental?