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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: RELEASE STOPPER? nonportable int64 constants in pg_crc.c
Дата
Msg-id 9644.985279056@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: RELEASE STOPPER? nonportable int64 constants in pg_crc.c  (Peter Eisentraut <peter_e@gmx.net>)
Список 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 по дате отправления:

Предыдущее
От: "Oliver Elphick"
Дата:
Сообщение: Missing operator for numeric comparison
Следующее
От: Steve Stock
Дата:
Сообщение: initdb and data directories with lost+found