On 18.04.24 02:31, Thomas Munro wrote:
On Sat, Mar 23, 2024 at 3:23 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
Thomas Munro <thomas.mu...@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.
