James Carlson wrote:
Alan Coopersmith wrote:
James Carlson wrote:
Alan Coopersmith wrote:
Joerg Schilling wrote:
It would be interesting to know how this interface change could make it into
POSIX as the intention of the POSIX standard is not to invalidate existing
interfaces.....
Was there ever a formal definition guaranteeing strcpy() worked for overlapping
strings or was that just an accident of the common implementation? The 1989 C
standard says it was undefined, and POSIX would build on that, not override it.
It's almost certainly just an accident, but does that matter? On the
one hand, we have "optimization" of a function that's rarely used to
copy more than a handful of bytes, while on the other we have silent
data corruption in existing binary applications.
How do those two square up to favor the current behavior?
I wasn't arguing against fixing the simple case, just against the claim
that POSIX changed this from "guaranteed to work" to "undefined".
Ah, ok. I think the argument from the other poster is that the original
definition was "whatever was in K&R," and one of those standards
(possibly the 1989 ISO C standard) reduced the level of guarantee
available for applications.
POSIX may well be a red herring, as it often seems to be ...
There is an assertion you've made that "strcpy" is only used to copy a
handful of bytes. While this *might* be true, I'm less convinced that
it is. It would be interesting to profile some big web servers, etc.
and see often strcpy gets called. It seesm (to me at least), that this
is an oft-called function, and its irrelevance for performance is not
(to me at least, again) immediately obvious.
- Garrett
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
