strcpy

[Chris Torek]

In article <4295 at hoptoad.uucp> gnu at hoptoad.uucp (John Gilmore) writes:
>The whole discussion here is about what the standard *should* say.

Precisely.

>In particular, both Chris and I have seen programs that depend on
>strcpy() being able to slide a string into lower array indices without
>destroying it.

Yes.  `strcpy(p, p+n)' is not an uncommon idiom.

>We think this is a valid interpretation of the man page.

(Well, perhaps the manual entry should be clarified.)

>... In our case, we know what the original
>source code said -- it copied left to right and made no bones about it.
>And so far nobody has named a compiler/library/OS/environment
>that *doesn't* just copy left to right.

To be fair, I *do* know of one:  The 4.3BSD Vax strcpy() uses the Vax
locc and movc3 instructions.  movc3 moves in whichever direction is
nondestructive.  This implies that

	strcpy(p+n, p)

moves the string *up* n bytes nondestructively, except when the string
is more than 65535 bytes long (the limit for a single locc/movc3).  I
would not mind having to change this if the standard mandated
left-to-right copying (which has a duplication effect on (p+n,p)-style
overlapping strings).  Alternatively, the standard could proclaim
that if the strings overlap and dst<src, the copy is done left-to-
right, otherwise the result is implementation dependent; this, however,
is an overly grotesque description.  I prefer the simple and well-
defined semantics of `if the strings overlap, the copy acts as if
it were performed from left to right, one byte at a time.'
-- 
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