From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@postgreSQL.org
Subject: Today's failures on buildfarm member longfin
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2838.1490714708.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 28 Mar 2017 11:25:08 -0400
Message-ID: <2839.1490714708@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Last night I updated longfin's host to the latest macOS and XCode point
releases.  That brought with it a new clang version which is slightly
pickier than the old: it's complaining about

log.c:5047:16: error: implicit conversion from 'int' to 'char' changes valu=
e from 255 to -1 [-Werror,-Wconstant-conversion]
        *(recptr++) =3D XLR_BLOCK_ID_DATA_SHORT;
                    ~ ^~~~~~~~~~~~~~~~~~~~~~~
../../../../src/include/access/xlogrecord.h:223:34: note: expanded from mac=
ro 'XLR_BLOCK_ID_DATA_SHORT'
#define XLR_BLOCK_ID_DATA_SHORT         255
                                        ^~~

(Manual investigation reveals there's about 5 of these altogether;
longfin's report stops with the first.)

Aleksander Alekseev complained about this previously in
https://www.postgresql.org/message-id/20170220141239.GD12278@e733.localdoma=
in
That thread went off into the weeds discussing whether or not we wanted
to do something about clang breaking autoconf's test for whether strlcpy
is declared, which we didn't particularly; but we forgot about the other
issues.

Since, per previous agreement[1], longfin is running with -Werror, we
either have to do something about this or revert the decision to make it
use -Werror --- and I'm not too pleased about the latter idea.  We should
not have made that agreement if we were going to abandon it at the first
sign of pain.

As noted in the other thread, we could either fix this in a
quick-and-dirty way by casting XLR_BLOCK_ID_DATA_SHORT and related
values to "char" explicitly, or we could run around and change the
target pointer variables to be "unsigned char *".  The latter could
prove to be pretty invasive if we try to carry it out fully, while
if we don't, then we're arguably just moving the ugly casts someplace
else.

Opinions?

			regards, tom lane

[1] https://www.postgresql.org/message-id/32279.1487355685@sss.pgh.pa.us


--=20
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers