public inbox for [email protected]
help / color / mirror / Atom feedFrom: Peter Eisentraut <[email protected]>
To: Thomas Munro <[email protected]>
To: Tom Lane <[email protected]>
Cc: Japin Li <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Cannot find a working 64-bit integer type on Illumos
Date: Thu, 18 Apr 2024 10:46:57 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+hUKG+ZwX-reVMHak3yo-63rrh9AJwEVGW4rCbsoLeSKO54Pg@mail.gmail.com>
References: <ME3P282MB3166F9D1F71F787929C0C7E7B6312@ME3P282MB3166.AUSP282.PROD.OUTLOOK.COM>
<[email protected]>
<ME3P282MB3166D876E9CB83009727A5ECB6312@ME3P282MB3166.AUSP282.PROD.OUTLOOK.COM>
<[email protected]>
<CA+hUKG+CR05ACFujUbeAd-yM+nNJBSpnyB=q3vbriCJuoSu9Ag@mail.gmail.com>
<[email protected]>
<CA+hUKG+ZwX-reVMHak3yo-63rrh9AJwEVGW4rCbsoLeSKO54Pg@mail.gmail.com>
On 18.04.24 02:31, Thomas Munro wrote:
> On Sat, Mar 23, 2024 at 3:23 PM Tom Lane <[email protected]> wrote:
>> Thomas Munro <[email protected]> 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.
view thread (10+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Cannot find a working 64-bit integer type on Illumos
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox