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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ian Lance Taylor <ian(at)airs(dot)com>
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:43:14
Message-ID: 5905.985470194@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Ian Lance Taylor <ian(at)airs(dot)com> writes:
> 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.

An interesting example. That will work as intended if and only if the
compiler regards 0xfeedface as unsigned --- if the constant is initially
treated as a signed int, then extension to 64 bits will propagate the
wrong bit value into the high-order bits.

Indeed, according to the ANSI C spec, 0xfeedface *should* be regarded as
unsigned in a machine whose ints are 32 bits. However, this conclusion
comes from the exact same paragraph that AIX got wrong to begin with.
I'm not sure that doing it this way actually affords any extra protection
against compilers that can't be trusted to handle integral constants
per-spec...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ian Lance Taylor 2001-03-24 22:05:05 Re: AW: AW: Re: RELEASE STOPPER? nonportable int64 constant s in pg_crc.c
Previous Message Ian Lance Taylor 2001-03-24 21:27:56 Re: AW: AW: Re: RELEASE STOPPER? nonportable int64 constant s in pg_crc.c