Re: RELEASE STOPPER? nonportable int64 constants in pg_crc.c

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> const uint64 crc_table[256] = {
> 0x0000000000000000##L64, 0x42F0E1EBA9EA3693##L64,
> 0x85E1C3D753D46D26##L64, 0xC711223CFA3E5BB5##L64,
>>
>> Hmm ... how portable is that likely to be?

> If the 'L' or 'LL' suffix is portable (probably), and token pasting is
> portable (yes), then the aggregate should be as well, because one is
> handled by the preprocessor and the other by the compiler.

It's just that I've never seen token-pasting applied to build anything
but identifiers and strings. In theory it should work, but theory does
not always predict what compiler writers will choose to warn about and
where. That "oversized integer" warning could be coming out of the
preprocessor.

BTW, my C book only talks about token-pasting as a step of macro body
expansion. Wouldn't we really need something like

SIXTYFOUR(0x0000000000000000), SIXTYFOUR(0x42F0E1EBA9EA3693),
SIXTYFOUR(0x85E1C3D753D46D26), SIXTYFOUR(0xC711223CFA3E5BB5),

where SIXTYFOUR(x) is conditionally defined to be "x##LL", "x##L",
or perhaps just "x"?

regards, tom lane