Re: OSX doesn't accept identical source/target for strcpy() anymore

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Matthias Schmitt <freak002(at)mmp(dot)lu>
Subject: Re: OSX doesn't accept identical source/target for strcpy() anymore
Date: 2013-10-28 18:11:12
Message-ID: 7718.1382983872@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Oct 28, 2013 at 12:11 PM, Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andres Freund 2013-10-28 18:26:53 Re: OSX doesn't accept identical source/target for strcpy() anymore
Previous Message Tom Lane 2013-10-28 17:55:23 Re: Darwin: make check fails with "child process exited with exit code 134"

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-10-28 18:19:42 Re: better atomics
Previous Message Robert Haas 2013-10-28 18:10:48 Re: better atomics