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 ... -- James Carlson 42.703N 71.076W <carls...@workingcode.com> _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
