Path: utzoo!mnetor!uunet!husc6!bloom-beacon!athena.mit.edu!peter
From: peter@athena.mit.edu (Peter J Desnoyers)
Newsgroups: comp.lang.c
Subject: Re: strcpy: "after the null has been copied"
Message-ID: <4460@bloom-beacon.MIT.EDU>
Date: 8 Apr 88 14:34:35 GMT
References: <7712@apple.Apple.Com> <7485@brl-smoke.ARPA> <10731@mimsy.UUCP> <793@cresswell.quintus.UUCP> <1033@mcgill-vision.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: peter@athena.mit.edu (Peter J Desnoyers)
Organization: Massachusetts Institute of Technology
Lines: 26
Summary: reducto ad absurdium

--
If strcpy is not constrained to copying characters only up to the
terminating null, then it is free to copy any characters after this
point. Hence I could write a conforming strcpy which would, in a
hardware-dependent manner, either erase my program or cause a write
protection error. (I know this isn't that hot an idea.)

The source of the confusion  seems to be this: 
 There are two orderings being referred to in this discussion.
Characters in memory are ordered by address, and characters are copied
in some chronological order. 

For the definition of strcpy to make sense, it must define the address
range to be modified in terms of the arguments, and thus refer to
ordering in memory space. It may be a nicety, but is not absolutely
necessary, for the definition to refer to ordering in time, as this
does not change the functionality for non-overlapping strings. 


				Peter Desnoyers
				peter@athena.mit.edu

[man strcpy gives me: "strcpy copies string s2 to s1, stopping after
the null character has been moved." This seems to refer to order in
time, and not explicitly refer to the memory range modified. I don't
think it is a very rigorous definition.]