Path: utzoo!mnetor!uunet!husc6!think!ames!umd5!mimsy!oddjob!gargoyle!att-ih!ihnp4!ihlpf!nevin1 From: nevin1@ihlpf.ATT.COM (00704a-Liber) Newsgroups: comp.lang.c Subject: Re: strcpy Message-ID: <4264@ihlpf.ATT.COM> Date: 4 Apr 88 22:11:26 GMT References: <3293@haddock.ISC.COM> <425@goofy.megatest.UUCP> Reply-To: nevin1@ihlpf.UUCP (00704a-Liber,N.J.) Organization: AT&T Bell Laboratories - Naperville, Illinois Lines: 42 In article <425@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes: >Geez. Enough already!! >Everybody knows what strcpy does: >void strcpy(str1, str2) > char* str1; > char* str2; >{ > while(*str1++ = *str2++) {;} >} First off, you got it slightly wrong (where is your return value?). Secondly, many implementations of C convert strcpy() into inline assembly code. It is conceivable that there may be hardware move instructions which will copy in a right-to-left order. Since 'good' C programs should not be depending on the implementation of strcpy() anyway, why should the implementation of it be restricted?? >If I remember correctly, it says as much right in K&R. I don't >think you want to break K&R without darn good reason. K&R gives *possible* ways of implementating strcpy() in C (see page 100 in the first edition). These are not entirely correct (they do not include the return value), nor are they all-inclusive. They are merely there as examples so that someone reading the book can understand how to implement a function like strcpy(). BTW, I wonder of the people who are saying that C won't be used on a multiprocessing machine are the same people who used to say that Unix will never be implemented on a Cray?? :-) :-) >If you want a function that does something else, give it another name. >"strcpy" is already taken. It seems that you, not I, want a function to do something other than what strcpy() is *guaranteed* to do now. -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_