strcpy (somewhat long)

[j.r.lupien]

>From article <810 at cresswell.quintus.UUCP>, by ok at quintus.UUCP (Richard A. O'Keefe):
+ In article <545 at anuck.UUCP>, jrl at anuck.UUCP (j.r.lupien) writes:
+> From article <793 at cresswell.quintus.UUCP>, by ok at 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 
+ 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.  

I realize this is not really addressing the issue of how strcpy should
or shouldn't work. The point of my RESPONSE has to do with the direct
interpretation of documentation. The above quoted statement does not
say that the copying stops as soon as the NUL gets copied. It just
does not say that, at all. If you assume that it intends to give
that impression, perhaps you are making a reasonable assumption,
but I only try adding words in to the statements from the manual
(words like "as soon as") after I have tried something out and I
find that the behavior does not correspond exactly to what the
manual says.

+ 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).

No, as I have just pointed out, the manual entry is NOT "just plain
wrong", it is just plain MISLEADING. Misleading is more than just
"not unprecedented", it seems to be a way of life in the UNIX manuals.

+ 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.

Indeed, but it fails just as fully to specify at what point the copying
stops after the NUL is copied. After means later in time. Something
else to specify immediacy is required before I will assume it.

+ 
+>   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".
[ADA example omitted]

I don't really agree that having things work the way you might expect
them to is "not bizarre". Few things surprise me more than to have my
first impression of what the manual said being born out in fact.

+ Not relying on the documentation, as (j.r.lupien) suggests,

No, no. I meant that you should not rely on a "reasonable interpretation"
of what the documentation says. Relying on LITERAL interpretation
will get you in trouble more often than it should. If you expect things
to behave in a "reasonable" manner on top of the literal specification,
some implementor's concept of what is reasonable will at some point
diverge from your own, and you will suffer unreasonably as a result.
I will indeed rely on the function to stop after the NUL has been
copied. If it stops before the NUL has been copied, I will call the
implementor and get them to fix either the library or the manual
so that they agree.

+ leads to people writing their own version of the C library so
+ that they know what will happen.

As you go on to explain, there are many very good reasons to 
"roll your own". Having the code do what you expect is only one
of them. However, I am an enthusiastic and appreciative user
of other people's libraries. I prefer to use "standard calls"
whenever possible. I just try not to read more into the documentation
than is actually written there in ink. 

twitch!mvuxa!anuxh!jrl

Watch out for that nuance!