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. 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?
0001-Use-int64_t-and-friends-from-stdint.h.patch
Description: Binary data
0002-Remove-traces-of-BeOS.patch
Description: Binary data
