strcpy

[Richard A. O'Keefe]

In article <4263 at ihlpf.ATT.COM>, nevin1 at ihlpf.ATT.COM (00704a-Liber) writes:
> In article <836 at cresswell.quintus.UUCP> ok at quintus.UUCP (Richard A. O'Keefe) writes:
> I agree that it is useful to have a function which can safely move strings
> with overlapping characters.  That is what memmove() is for.
Nope, memmove() is for when IN ADDITION you already know the exact amount
you want to move.

> 	"If copying takes place between objects that overlap, the behavior is
> 	undefined."
> You may not like the answer, but the standard answers the question just the
> same.
Refusing to answer is _not_ an answer!

> In order to copy possibly overlapping strings, you need to know the length
> of the source string.  Therefore, give a source string s2 (char *s2) and a
> destination string s1 (char *s1):
> 	(char *)memmove((void *)s1, (void *)s2, strlen(s2) + (size_t)1)
> will accomplish that you would want a strmove() to do.

(a) I don't want "to copy possibly overlapping strings", I want to move
    a NUL-terminated sequence to another area of memory which may overlap
    the current copy of that sequence.  I am happy to destroy the original
    (so it's "move", not "copy"), and in general I neither know nor care
    whether the destination has a NUL in it (so one of the areas might not
    be a "string").	[Actually, my objection to calling a move a copy
    counts against me:  strcpy() is a copy only when the two areas don't
    overlap.]
(b) if you are moving towards lower addresses, you do _not_ need to know
    the length of the source string in advance, but can check as you go.
    The implementor of a strmov() function can check for this, and only
    calculate strlen() when necessary.

Anyway, I give in.  From now on I'll stick with my own code, so that I
can be _sure_ what it does.

[PS: is it really so vital to wring the very last microsecond out of
 strcpy?  I once went through a program changing things like
	sprintf(buffer, "foo%s", X);
 to	strcpy(buffer, "foo"), strcpy(buffer+3, X);
 and it didn't make any appreciable difference.  Letting the implementor
 optimise the whatever out of strcpy() while not requiring that 1.0+1.0
 be a good approximation to 2.0 doesn't seem like quite the right balance.]