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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>
Cc: "'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:46:35
Message-ID: 2754.985229195@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at> writes:
> Recent changes in pg_crc.c (64 bit CRC) introduced non portable constants of the form:

> -c -o pg_crc.o pg_crc.c
> 287 | 0x0000000000000000, 0x42F0E1EBA9EA3693,
> ............................a..................
> a - 1506-207 (W) Integer constant 0x42F0E1EBA9EA3693 out of range.

Please observe that this is a warning, not an error. Your proposed
fix is considerably worse than the disease, because it will break on
compilers that do not recognize "LL" constants, to say nothing of
machines where L is correct and LL is some yet wider datatype.

I'm aware that some compilers will produce warnings about these
constants, but there should not be any that fail completely, since
(a) we won't be compiling this code unless we've proven that the
compiler supports a 64-bit-int datatype, and (b) the C standard
forbids a compiler from requiring width suffixes (cf. 6.4.4.1 in C99).

I don't think it's a good tradeoff to risk breaking some platforms in
order to suppress warnings from overly anal-retentive compilers.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message The Hermit Hacker 2001-03-22 02:49:52 Re: Re: RELEASE STOPPER? nonportable int64 constants in pg_crc.c
Previous Message Limin Liu 2001-03-22 02:37:37 Re: Can I use SPI in postgres.c