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
