Path: utzoo!mnetor!uunet!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: strcpy
Message-ID: <7518@brl-smoke.ARPA>
Date: 22 Mar 88 18:39:13 GMT
References: <7712@apple.Apple.Com> <7485@brl-smoke.ARPA> <10731@mimsy.UUCP> <7506@brl-smoke.ARPA> <10753@mimsy.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 12

In article <10753@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
-In article <7506@brl-smoke.ARPA> gwyn@brl-smoke.ARPA (Doug Gwyn) writes:
->This usage was never a good idea, because a valid implementation of
->strcpy() would be to copy right-to-left rather than left-to-right
-I agree that a generic block copy operation (one of {memcpy, memmove}
----I cannot remember which allows overlap) might do this; I do not
-agree that strcpy() may be implemented that way.  (I could be wrong.)

I've never seen a specification of strcpy() that promised left-to-right
processing.  The dpANS specifies (redundantly, now that noalias
qualifiers are shown on the parameters) that copying between overlapping
objects results in undefined behavior.