From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: Today's failures on buildfarm member longfin
In-reply-to: <20170328153118.omm476nd6lrslxji@alap3.anarazel.de>
References: <2839.1490714708@sss.pgh.pa.us>
 <20170328153118.omm476nd6lrslxji@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Tue, 28 Mar 2017 08:31:18 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4251.1490716580.1@sss.pgh.pa.us>
Date: Tue, 28 Mar 2017 11:56:20 -0400
Message-ID: <4252.1490716580@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Andres Freund <andres@anarazel.de> writes:
> On 2017-03-28 11:25:08 -0400, Tom Lane wrote:
>> 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.

> If necessary we could do that more targeted with
> -Wno-error=constant-conversion, but I think we should just fix this.

Yeah, that option seems like it would lose important error detection.

>> 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 *".

> I think both are ok with me.  Could also just use memcpy instead of
> direct assignment, but that seems too complicated.  I'd personally just
> go with Aleksander's casts.

Further investigation says that these warnings now also appear in the
9.5 and 9.6 branches, which were previously warning-clean except for
ye olde unused-variable flex bug.  So I'd like a solution that can be
back-patched, which says that the localized casts to char are the way to
go.  Maybe somebody else will want to undertake a more general cleanup,
but I don't want to spend time on that right now.

			regards, tom lane


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