Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!gargoyle!oddjob!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.lang.c Subject: Re: strcpy Message-ID: <10895@mimsy.UUCP> Date: 2 Apr 88 04:10:37 GMT References: <7712@apple.Apple.Com> <7485@brl-smoke.ARPA> <10731@mimsy.UUCP> <4295@hoptoad.uucp> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 39 In article <4295@hoptoad.uucp> gnu@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