From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Generating configure from configure.ac |
Date: | 2024-11-26 05:07:59 |
Message-ID: | 1598141.1732597679@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> . o O ( I wonder if that missing Debian/Ubuntu bugfix[1] is why our
> AIX animals have -D_LARGE_FILES=1 jammed into $CC, even though
> AC_SYS_LARGEFILES claims to understand AIX )
I'm dubious. The two likely results if off_t is 32 bits are
(1) the compiler shifts the 1 off into never-never land, producing
zero, or (2) the compiler throws an error about shift distance too
large. Either one will lead to the test failing as-desired.
Yeah, the C spec theoretically licenses the compiler to halt
and catch fire, but that's not going to happen in practice.
(Thus Sven Joachim's doubt in the linked bug discussion that
anything is actually broken.)
It seems plausible to me that the -D_LARGE_FILES=1 settings in our
AIX animals' configuration are carried over from some dim past where
we didn't have this configure test, or it was implemented even less
correctly than now. I wonder whether Noah has any records of their
origin.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bertrand Drouvot | 2024-11-26 05:16:05 | Re: Potential ABI breakage in upcoming minor releases |
Previous Message | Hayato Kuroda (Fujitsu) | 2024-11-26 05:03:01 | RE: Parallel heap vacuum |