Path: utzoo!mnetor!uunet!husc6!ncar!ames!lll-tis!mordor!sri-spam!sri-unix!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: strcpy
Message-ID: <810@cresswell.quintus.UUCP>
Date: 24 Mar 88 05:46:58 GMT
References: <793@cresswell.quintus.UUCP> <545@anuck.UUCP>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 58

In article <545@anuck.UUCP>, jrl@anuck.UUCP (j.r.lupien) writes:
> From article <793@cresswell.quintus.UUCP>, by ok@quintus.UUCP (Richard A. O'Keefe):
> > The UNIX manuals say of strcpy(s1, s2) that it
> > 	"copies s2 to s1, stopping after the null character has been copied."
> > While they doesn't strictly speaking say anything about the order in which
> > the other characters are copied, they _do_ say that the NUL character must
> > be copied last, so 
> Stopping after something occurs, as with "after the NULL has been copied"
> does NOT equate, as you go on to assume, to "nothing will be done after
> the NULL[*] is copied. The function will return immediately."

That's not what I assumed.  The function could well compute factorial 5000.
So what?  The manual says that COPYING stops after the NUL character has
been copied.  So whatever strcpy does after copying NUL, either it doesn't
copy any part of s2 to s1, or the manual entry is just plain wrong (which
would not be unprecedented).  The point of my message was that AT&T
documentation provides some warrant for expecting a left-to-right order
rather than some other order.

The VMS C documentation says that strcpy(str_1, str_2)
	"copies str_2 into str_1, stopping after copying str_2's NUL character."
which again says that COPYING stops after the NUL is copied.

>   The moral of this is, don't depend on bizarre side effects unless

The order in which strcpy works is hardly a "bizarre side effect".
The ADA LRM takes the trouble to point out in section 5.2.1 that the
effect of assignments such as
	A : STRING(1..31);
	A(1..9) := "tar sauce";
	A(4..12) := A(1..9);
yields A(1..12) = "tartar sauce".  There doesn't seem to be any good
reason for C being less well defined.  We want a block transfer which
works correctly with overlapping blocks.  We want a "string" transfer
which is defined to copy left to right (only one direction, because
C "strings" have one easy end (p) and one hard end (p+strlen(p))).
And there is room for incompletely specified block/string
transfers as well.

Not relying on the documentation, as (j.r.lupien) suggests, leads to
people writing their own version of the C library so that they know
what will happen.  If the ANSI C library doesn't include something
like strcpy() which is defined to work left to right, people will
have to keep on rolling their own.

[*] The name of the null character is NUL, not NULL, just as
    the name of the bell character is BEL, not BELL.

PS: I have found on some machines that calling my own routine
    char *mycpy(dst, src)
	char *dst, *src;
	{    
	    register char *d, *s;
	    for (d = dst, s = src; *d++ = *s++; ) ;
	    return dst;
	}
    can be FASTER than calling the vendor's strcpy()!  You might like
    to measure it for yourself.  I was very surprised by this result.