On 2013-10-28 14:11:12 -0400, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Mon, Oct 28, 2013 at 12:11 PM, Andres Freund <and...@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.ga5...@awork2.anarazel.de Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers