Re: OSX doesn't accept identical source/target for strcpy() anymore
От | Tom Lane |
---|---|
Тема | Re: OSX doesn't accept identical source/target for strcpy() anymore |
Дата | |
Msg-id | 7718.1382983872@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: OSX doesn't accept identical source/target for strcpy() anymore (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: OSX doesn't accept identical source/target for
strcpy() anymore
Re: OSX doesn't accept identical source/target for strcpy() anymore Re: OSX doesn't accept identical source/target for strcpy() anymore |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: