Path: utzoo!mnetor!uunet!ncc!alberta!att-ih!ihnp4!ihlpf!nevin1 From: nevin1@ihlpf.ATT.COM (00704a-Liber) Newsgroups: comp.lang.c Subject: Re: More on strcpy() Message-ID: <4419@ihlpf.ATT.COM> Date: 14 Apr 88 15:31:41 GMT References: <7712@apple.Apple.Com> <7485@brl-smoke.ARPA> <10731@mimsy.UUCP> <4343@ihlpf.ATT.COM> <10987@mimsy.UUCP> <4383@ihlpf.ATT.COM> <904@mit-caf.UUCP> Reply-To: nevin1@ihlpf.UUCP (00704a-Liber,N.J.) Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 21 Summary: Have we come full circle yet? In article <904@mit-caf.UUCP> vlcek@mit-caf.UUCP (Jim Vlcek) writes: >Why not define strcpy() such that the destination is guaranteed to be >equivalent to the original (before the move) source string? While >this *suggests* an implementation, it does not out-and-out *specify* >it, yet it still seems to me to provide the behavior desired. One problem with this method is that the length of the source string must be known *first* in order to get the copy completely right. This is not as efficient as the way strcpy() is usually defined; ie, 'while (*dst++ = *src++);', because two passes are required over the src string (one to find the length and one to perform the copy). The other problem I have with this definition, as well as with the proposal that strcpy() be defined as having the same result as the 'while' loop I stated above, is that strcpy() can LEGALLY be used to modify the *src* string. It is this property becoming legal that I object to. -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_