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

Reply via email to