vlcek@mit-caf.UUCP (Jim Vlcek) (04/14/88)
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.
--
Jim Vlcek
vlcek@caf.mit.edu
!{ihnp4,harvard,seismo,rutgers}!mit-eddie!mit-caf!vlceknevin1@ihlpf.ATT.COM (00704a-Liber) (04/14/88)
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." / (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blah
karl@haddock.ISC.COM (Karl Heuer) (04/15/88)
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? Because, in order for this to work on both strcpy(s,s+1) and strcpy(s+1,s), the implementation has to do extra work to guarantee nondestructiveness. If strcpy is being inline-expanded by the compiler, this can be a significant overhead which is seldom necessary. Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
nevin1@ihlpf.ATT.COM (00704a-Liber) (04/16/88)
In article <3477@haddock.ISC.COM> karl@haddock.ima.isc.com (Karl Heuer) writes: >Because, in order for this to work on both strcpy(s,s+1) and strcpy(s+1,s), >the implementation has to do extra work to guarantee nondestructiveness. If >strcpy is being inline-expanded by the compiler, this can be a significant >overhead which is seldom necessary. Actually, I don't think that it is even possible to nondestructively copy overlapping strings. The only thing that could possibly be guaranteed is that the dst string becomes what used to be the src string. That isn't being done now by most implementations of strcpy(), and I don't want to see it added due to it beingg inherently inefficient (especially since there *is* a function which can be used in it's place in those few situations which need it). -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blah