strcpy

[Dave Jones]

in article <4264 at ihlpf.ATT.COM>, nevin1 at ihlpf.ATT.COM (00704a-Liber) says:
> 
> 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?).

  Okay.  You win round one. It's supposed to return a char*, not void.
  Says so in the documentation. K&R is wrong.  Gad!  Is nothing sacred?

> Secondly, many implementations of C convert strcpy() into inline
> assembly code.

  So?  If they get it right, that's fine with me.

>  It is conceivable that there may be hardware move
> instructions which will copy in a right-to-left order.

  Then you better not use that conceivable hardware move! It doesn't do
  the right thing.  Besides, how is that right-to-left instruction
  going to find the terminating null character?
  
  I cut this directly out of the on-line UNIX documentation:      

	strcpy copies string s2 to s1, stopping after the null char-
     	acter has been copied.

  If you expect the jury to believe that means anything other than
  a "left-to-right" copy, you better have a darn good lawyer.

  "Your Honor, the copy stops after the null character has been copied.
  STOPS.  Nothing is copied after the null character."

  "But Your Honor, it stops after EVERY character is copied.  It
  doesn't say it stops IMMEDIATELY after the null character is copied.
  They just phrased it that way to trick you."

  "Your Honor, that is very silly."

> Since 'good' C
> programs should not be depending on the implementation of
> strcpy() anyway, why should the implementation of it be restricted??
>

Because not all C programs are 'good' ones.  The ones you and I write are,
of course.  But there's all those other programs out there, just waiting
to rear their shrowded strcpys in agony.  I get bored chasing down bugs
in old brittle code.  I'd rather be at the beach.
 
>>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().
> 

Probably they were meant to be only example implementations, but
I'll guess many have taken it quite literally, and programmed accordingly.

> 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??  :-) :-)
> 

Yep.  Same lot.  Bunch of Fortran geeks.  Just ignore them.

>>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.

I never said I want the function to do what it is *guaranteed* to do now.
I want it to do what it *does* 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


If you want to attempt a counterrebuttal (and I don't recommend it), 
I won't *string*it*out*.  (Urk.)  I'll let you have the last word.  It's 
not really an earth-shaking matter is it?




		Dave (Break it, you bought it) Jones