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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
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 02:51:40
Message-ID: 2795.985229500@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> I don't think it's the answer either. The patch assumes that int64 ==
> long long. The ugly solution might have to be:

> #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? 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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-03-22 02:54:23 Re: elog with automatic file, line, and function
Previous Message The Hermit Hacker 2001-03-22 02:49:52 Re: Re: RELEASE STOPPER? nonportable int64 constants in pg_crc.c