strcpy

[Chris Torek]

In article <836 at cresswell.quintus.UUCP> ok at quintus.UUCP (Richard
A. O'Keefe) writes:
>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().

Unless there were some overriding reason not to do so, I agree.  The
claim as to efficiency is similar to the claim that Unix should have
a `spawn' system call.  After all, most of the time you are copying
from one string to another.  After all, most of the time you are
going to exec immediately after a fork.

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

No.

This sort of thing can lead to a function space explosion: strcpy for
one-to-another; strltor for left-to-right copy; strrtol for right-to-
left; strmove for whichever is `right'; `strunsharedcpy' for memory
regions that are guaranteed unshared; ....

Where does one stop?  That is a matter of taste.  In the case of strcpy,
I happen to believe that defining it to work left-to-right is worth
any expense it may cause (because I believe that cost will be small
if not zero).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris