Joerg Schilling wrote:
Bill Holler <[email protected]> wrote:
More information is available. strcpy was intentionally written this way for
performance not due
to a copy-paste bug. These overlapping cases where not validated because
overlapping
strings is explicitly undefined.
Well, strcpy() _was_ definitely not undefined for overlapping strings,
see older UNIX man pages. The strcpy() definition rather has been changed
because some people felt that it could allow them to write cheap and fast
implementations.
My copy of K&R edition 2 says "undefined" on page 249, so I think it's
been undefined for a while. Except for memmove which explicitly checks
for a LtoR or RtoL copy.
More to the point, the vanilla (non optimized) version of strcpy in
libc/port/gen/strcpy.c, and which has not changed since V7 Unix at
least, definitely won't work for overlapping strings for the case that
s1>s2:
while (*s1++ = *s2++)
;
So what you're really arguing in favor of is that overlapping strings
should be supported but only when s2>=s1. It's certainly possible that
you're not the only person who has relied on this, based on assumptions
of the underlying implementation using byte-by-byte copy. But the main
point is that strcpy() has always been undefined at least for
overlapping s1>s2 cases, documentation or not.
Note that the only way to protect against the s1>s2 case is to first
count the string length (via a loop) before then doing memmove(). It
seems unlikely any libc implementation has ever written the function
this way...
Hugh.
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
