Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Oct 28, 2013 at 12:11 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>> There have been previous discussions about fixing strcpy calls with
>> identical source/destination (same for memcpy) but it was deemed not
>> worth the effort. I don't really see an alternative to fixing it now.
> Ugh. Why in the world would Apple break this?
It's broken already; the C and POSIX standards say of strncpy:
If copying takes place between objects that overlap, the behavior is undefined.
Both gcc and glibc have been moving steadily in the direction of
aggressively exploiting "undefined behavior" cases for optimization
purposes. I don't know if there is yet a platform where strncpy with
src == dest behaves oddly, but we'd be foolish to imagine that it's
not going to happen eventually. If anything, Apple is probably doing
us a service by making it obvious where we're failing to adhere to spec.
However ... I still can't replicate this here, and as you say, there's
about zero chance of keeping our code clean of this problem unless we
can set up a buildfarm member that will catch it.
regards, tom lane
