Re: AW: AW: Re: RELEASE STOPPER? nonportable int64 constant s in pg_crc.c

From: Ian Lance Taylor <ian(at)airs(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, Zeugswetter Andreas SB <ZeugswetterA(at)wien(dot)spardat(dot)at>, "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: AW: AW: Re: RELEASE STOPPER? nonportable int64 constant s in pg_crc.c
Date: 2001-03-24 21:27:56
Message-ID: siu24ig8mb.fsf@daffy.airs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> If you look closely, the configure test is not simply checking whether
> LL is accepted, it is checking whether we can construct an acceptable
> constant by macroized token-pasting. That's a slightly larger
> assumption, but it's the one the code must actually make to cover
> AIX's problem. As I remarked before, I think that ## is more typically
> used to paste identifiers and strings together; I don't really want to
> bet that pasting 0xNNN ## LL will work on every compiler.
>
> Mainly it's a schedule-driven thing. I don't want to take any risk that
> a last-minute patch to work around AIX's broken compiler will break any
> other platforms. If we had found this problem before beta cycle
> started, I would be more willing to say "let's try it and find out
> whether it works everywhere".

A safe way to construct a long long constant is to do it using an
expression:
((((uint64) 0xdeadbeef) << 32) | (uint64) 0xfeedface)
It's awkward, obviously, but it works with any compiler.

Ian

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-03-24 21:43:14 Re: AW: AW: Re: RELEASE STOPPER? nonportable int64 constant s in pg_crc.c
Previous Message Tom Lane 2001-03-24 18:31:07 Re: Call for platforms