Re: Cannot find a working 64-bit integer type on Illumos

On Sat, Mar 23, 2024 at 3:23 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Thomas Munro <thomas(dot)munro(at)gmail(dot)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.

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. So I think we still need to
probe for INT64_MODIFIER at configure-time. Here's one way, but I can
see it's not working on Clang/Linux... perhaps instead of that dubious
incantation I should try compiling some actual printfs and check for
warnings/errors.

I think INT64CONST should just point to standard INT64_C().

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?

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?