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.
