Path: utzoo!mnetor!uunet!husc6!bloom-beacon!gatech!ncsuvx!mcnc!rti!xyzzy!throopw From: throopw@xyzzy.UUCP (Wayne A. Throop) Newsgroups: comp.lang.c Subject: Re: strcpy Message-ID: <725@xyzzy.UUCP> Date: 28 Mar 88 20:30:12 GMT References: <793@cresswell.quintus.UUCP> <545@anuck.UUCP> <810@cresswell.quintus.UUCP> Organization: Data General, RTP NC. Lines: 36 >,>>> ok@quintus.UUCP (Richard A. O'Keefe) >> jrl@anuck.UUCP (j.r.lupien) >>> The UNIX manuals say of strcpy(s1, s2) that it >>> "copies s2 to s1, stopping after the null character has been copied." >> 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 It does indeed say that the copying stops after the null has been copied. But this in no way indicates that no more copying occurs after the copy of the null has been made. Consider: The car went careening down the street, stopping after the pedestrian had been hit. Do you think this means that the car does no more traveling after the impact? I think not. If that had been meant, it should have said "stopping immediately after the pedestrian had been hit" or "stopping when the pedestrian had been hit". I think the same applies to the manual entry. And apparently other people think so too, since the ANSI clarification of this passage does not guarantee that the null is the last item copied. I'm fairly certain that the only thing the phrasing of the manual guarantees, (or even is intended to guarantee)) is that the null is copied during the process, and not what the relative order is. -- Sometimes I wonder whether God enjoys Christmas. --- Horace Rumpole -- Wayne Throop !mcnc!rti!xyzzy!throopw