Re: RELEASE STOPPER? nonportable int64 constants in pg_crc.c - Mailing list pgsql-hackers

From Tom Lane
Subject Re: RELEASE STOPPER? nonportable int64 constants in pg_crc.c
Date
Msg-id 9644.985279056@sss.pgh.pa.us
Whole thread Raw
In response to Re: RELEASE STOPPER? nonportable int64 constants in pg_crc.c  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.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


pgsql-hackers by date:

Previous
From: "Oliver Elphick"
Date:
Subject: Missing operator for numeric comparison
Next
From: Steve Stock
Date:
Subject: initdb and data directories with lost+found