On 2013-10-28 14:11:12 -0400, Tom Lane wrote:
> 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.
It'd be neat if we could get a buildfarm animal up that uses valgrind -
which would catch such and lots of other errors. That's where the topic
has come up in the past:
http://www.postgresql.org/message-id/20110312133224.GA7833%40tornado.gateway.2wire.net
http://www.postgresql.org/message-id/20130217142209.GA5073@awork2.anarazel.de
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services