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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers