Feedback-ID: ie0a040ee:Fastmail
Message-ID: <7cf1dcb7-306f-4418-bf25-bdc75130db10@eisentraut.org>
Date: Thu, 18 Apr 2024 10:46:57 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Cannot find a working 64-bit integer type on Illumos
To: Thomas Munro <thomas.munro@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Japin Li <japinli@hotmail.com>, Andres Freund <andres@anarazel.de>,
 PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
References: <ME3P282MB3166F9D1F71F787929C0C7E7B6312@ME3P282MB3166.AUSP282.PROD.OUTLOOK.COM>
 <20240322165305.6zrtxcmzdrywvmsu@awork3.anarazel.de>
 <ME3P282MB3166D876E9CB83009727A5ECB6312@ME3P282MB3166.AUSP282.PROD.OUTLOOK.COM>
 <944094.1711128356@sss.pgh.pa.us>
 <CA+hUKG+CR05ACFujUbeAd-yM+nNJBSpnyB=q3vbriCJuoSu9Ag@mail.gmail.com>
 <1229869.1711160593@sss.pgh.pa.us>
 <CA+hUKG+ZwX-reVMHak3yo-63rrh9AJwEVGW4rCbsoLeSKO54Pg@mail.gmail.com>
Content-Language: en-US
From: Peter Eisentraut <peter@eisentraut.org>
In-Reply-To: <CA+hUKG+ZwX-reVMHak3yo-63rrh9AJwEVGW4rCbsoLeSKO54Pg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/7cf1dcb7-306f-4418-bf25-bdc75130db10%40eisentraut.org>
Precedence: bulk

On 18.04.24 02:31, Thomas Munro wrote:
> On Sat, Mar 23, 2024 at 3:23 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Thomas Munro <thomas.munro@gmail.com> writes:
>>> . o O ( int64_t, PRIdi64, etc were standardised a quarter of a century ago )
>>
>> Yeah.  Now that we require C99 it's probably reasonable to assume
>> that those things exist.  I wouldn't be in favor of ripping out our
>> existing notations like UINT64CONST, because the code churn would be
>> substantial and the gain minimal.  But we could imagine reimplementing
>> that stuff atop <stdint.h> and then getting rid of the configure-time
>> probes.
> 
> I played around with this a bit, but am not quite there yet.

Looks promising.

> printf() is a little tricky.  The standard wants us to use
> <inttypes.h>'s PRId64 etc, but that might confuse our snprintf.c (in
> theory, probably not in practice).  "ll" should have the right size on
> all systems, but gets warnings from the printf format string checker
> on systems where "l" is the right type.

I'm not sure I understand the problem here.  Do you mean that in theory 
a platform's PRId64 could be something other than "l" or "ll"?

> For limits, why do we have this:
> 
> - * stdint.h limits aren't guaranteed to have compatible types with our fixed
> - * width types. So just define our own.
> 
> ?  I mean, how could they not have compatible types?

Maybe this means something like our int64 is long long int but the 
system's int64_t is long int underneath, but I don't see how that would 
matter for the limit macros.

> I noticed that configure.ac checks if int64 (no "_t") might be defined
> already by system header pollution, but meson.build doesn't.  That's
> an inconsistency that should be fixed, but which way?  Hmm, commit
> 15abc7788e6 said that was done for BeOS, which we de-supported.  So
> maybe we should get rid of that?

I had a vague recollection that it was for AIX, but the commit indeed 
mentions BeOS.  Could be removed in either case.