Path: utzoo!mnetor!uunet!husc6!purdue!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: strcpy
Message-ID: <10861@mimsy.UUCP>
Date: 30 Mar 88 21:36:28 GMT
References: <793@cresswell.quintus.UUCP> <545@anuck.UUCP> <4190@ihlpf.ATT.COM> <836@cresswell.quintus.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 29

In article <836@cresswell.quintus.UUCP> ok@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@mimsy.umd.edu	Path:	uunet!mimsy!chris