Re: AW: AW: Re: RELEASE STOPPER? nonportable int64 constant s in pg_crc.c - Mailing list pgsql-hackers

From Tom Lane
Subject Re: AW: AW: Re: RELEASE STOPPER? nonportable int64 constant s in pg_crc.c
Date
Msg-id 22918.985450366@sss.pgh.pa.us
Whole thread Raw
In response to Re: AW: AW: Re: RELEASE STOPPER? nonportable int64 constant s in pg_crc.c  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> I don't see what this configure check buys us, since it does not check for
> anything that's ever been reported not working.  Do you think there are
> platforms that have 'long long int' but no 'LL' suffix?  That seems more
> than unlikely.

Well, I don't know.  Up till yesterday I would have said that there were
no compilers that violated the C specification (not to mention twenty
years of traditional practice) in the handling of integral constants
of varying widths.

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".

Yeah, it's paranoia, but considering that the whole thing is an exercise
in covering up a "shouldn't happen" compiler bug, I think paranoia is
not so unreasonable.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: 7.1 docs
Next
From: Tom Lane
Date:
Subject: Re: Re: Call for platforms