Skip site navigation (1) Skip section navigation (2)

Today's failures on buildfarm member longfin

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Today's failures on buildfarm member longfin
Date: 2017-03-28 15:25:08
Message-ID: 2839.1490714708@sss.pgh.pa.us (view raw, whole thread or download thread mbox)
Thread:
Lists: pgsql-hackers
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 value from 255 to -1 [-Werror,-Wconstant-conversion]
        *(recptr++) = XLR_BLOCK_ID_DATA_SHORT;
                    ~ ^~~~~~~~~~~~~~~~~~~~~~~
../../../../src/include/access/xlogrecord.h:223:34: note: expanded from macro '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.localdomain
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


Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2017-03-28 15:26:01
Subject: Re: [POC] A better way to expand hash indexes.
Previous:From: David SteeleDate: 2017-03-28 15:23:39
Subject: Re: GUC for cleanup indexes threshold.

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group