Re: OSX doesn't accept identical source/target for strcpy() anymore
От
Andres Freund
Тема
Re: OSX doesn't accept identical source/target for
strcpy() anymore
Дата
Msg-id
20131028182653.GD20248@awork2.anarazel.de
Ответ на
Список
Дерево обсуждения
Re: OSX doesn't accept identical source/target for strcpy() anymore Tom Lane <tgl@sss.pgh.pa.us>
Re: OSX doesn't accept identical source/target for
strcpy() anymore Andres Freund <andres@2ndquadrant.com>
Re: OSX doesn't accept identical source/target for strcpy() anymore Tom Lane <tgl@sss.pgh.pa.us>
Re: OSX doesn't accept identical source/target for
strcpy() anymore Andres Freund <andres@2ndquadrant.com>
Re: OSX doesn't accept identical source/target for strcpy() anymore Tom Lane <tgl@sss.pgh.pa.us>
Re: OSX doesn't accept identical source/target for
strcpy() anymore Andres Freund <andres@2ndquadrant.com>
Re: OSX doesn't accept identical source/target for strcpy() anymore Tom Lane <tgl@sss.pgh.pa.us>
Re: OSX doesn't accept identical source/target for strcpy() anymore Noah Misch <noah@leadboat.com>
Re: OSX doesn't accept identical source/target for strcpy() anymore Tom Lane <tgl@sss.pgh.pa.us>
Re: OSX doesn't accept identical source/target for strcpy() anymore Noah Misch <noah@leadboat.com>
Re: OSX doesn't accept identical source/target for strcpy() anymore Andres Freund <andres@2ndquadrant.com>
Re: OSX doesn't accept identical source/target for strcpy() anymore Noah Misch <noah@leadboat.com>
On 2013-10-28 14:11:12 -0400, Tom Lane wrote: > Robert Haas writes: > > On Mon, Oct 28, 2013 at 12:11 PM, Andres Freund 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
В списке pgsql-hackers по дате отправления
От: didier
Дата: