Noah Misch <noah@leadboat.com> writes:
> On Wed, Mar 15, 2017 at 12:04:11PM +0300, Aleksander Alekseev wrote:
>> If it no too much trouble could you please explain what will happen
>> on such platforms?
> Both port.h and a system header will furnish a strlcpy() declaration. The #if
> you modified exists to avoid that, and your change would make it ineffective
> for Clang. This will have no symptoms, or it will elicit a warning.
The reason why this is bad is that port.h's declaration might be different
from the system headers'. That's not hypothetical; for example, on my
Mac laptop, strlcpy is declared
size_t strlcpy(char * restrict dst, const char * restrict src, size_t size);
whereas of course there's no "restrict" in port.h. To make matters worse,
it looks like strlcpy is actually a macro expanding to
'__builtin___strlcpy_chk'. And the compiler on this box *is* clang,
meaning the proposed patch would affect it. When I try it, I get
boatloads of errors (not warnings) like these:
In file included from ../../src/include/postgres_fe.h:25:
In file included from ../../src/include/c.h:1125:
../../src/include/port.h:403:15: error: expected parameter declarator
extern size_t strlcpy(char *dst, const char *src, size_t siz); ^
/usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy' __builtin___strlcpy_chk (dest, src, len,
__darwin_obsz(dest)) ^
../../src/include/port.h:403:15: error: conflicting types for '__builtin___strlcpy_chk'
/usr/include/secure/_string.h:105:3: note: expanded from macro 'strlcpy'
In short, if this were to get committed, it would get reverted within
minutes, because more than a few of us use Macs.
regards, tom lane