strcpy

[00704a-Liber]

In article <425 at goofy.megatest.UUCP> djones at 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."
/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah