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

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: RELEASE STOPPER? nonportable int64 constants in pg_crc.c
Date: 2001-03-22 16:40:00
Message-ID: Pine.LNX.4.30.0103221736370.1208-100000@peter.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane writes:

> > #if <int64 == long>
> > #define L64 L
> > #else
> > #define L64 LL
> > #endif
>
> > 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.

> I don't want to suppress warnings on a few boxes at the cost of
> breaking even one platform that would otherwise work. See my reply to
> Andreas.

It's possible that there might be one that warns and truncates, but that's
unlikely. Why are there suffixes for integer (not float) constants
anyway?

--
Peter Eisentraut peter_e(at)gmx(dot)net http://yi.org/peter-e/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Steve Stock 2001-03-22 16:41:05 initdb and data directories with lost+found
Previous Message Tom Lane 2001-03-22 16:37:36 Re: RELEASE STOPPER? nonportable int64 constants in pg_crc.c