Thread: Re: Today's failures on buildfarm member longfin

On 2017-03-28 11:25:08 -0400, Tom Lane wrote:
> 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.)

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


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

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.

Greetings,

Andres Freund

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