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

Thomas Munro <thomas.munro@gmail.com>

From: Thomas Munro <thomas.munro@gmail.com>

To: Peter Eisentraut <peter@eisentraut.org>

Cc: Tom Lane <tgl@sss.pgh.pa.us>, Japin Li <japinli@hotmail.com>, Andres Freund <andres@anarazel.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2024-04-18T20:29:27Z

Lists: pgsql-hackers

Attachments

v2-0001-Use-int64_t-support-from-stdint.h-and-inttypes.h.patch (application/octet-stream) patch v2-0001
v2-0002-Remove-traces-of-BeOS.patch (application/octet-stream) patch v2-0002

On Thu, Apr 18, 2024 at 8:47 PM Peter Eisentraut <peter@eisentraut.org> wrote:
> 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"?

Yes.  I don't know why anyone would do that, and the systems I checked
all have the obvious definitions, eg "ld", "lld" etc.  Perhaps it's an
acceptable risk?  It certainly gives us a tidier result.

For discussion, here is a variant that fully embraces <inttypes.h> and
the PRI*64 macros.

Commits

Move pg_int64 back to postgres_ext.h
- e56a601e0678 19 (unreleased) landed
- 409543da5411 18.0 landed
pgbench: Make set_random_seed() 64-bit everywhere.
- 53a2a1564ae4 18.0 landed
Use PRI?64 instead of "ll?" in format strings (continued).
- a0ed19e0a9ef 18.0 landed
Fix order of -I switches for building pg_regress.o.
- f186f90e55b7 17.5 landed
- cb36f8ec2124 18.0 landed
libpq: Deprecate pg_int64.
- 3c86223c9982 18.0 landed
Use PRI*64 instead of "ll*" in format strings (minimal trial)
- 15a79c73111f 18.0 landed
Fix header inclusion order in c.h.
- 71cb352904c1 18.0 landed
Use <stdint.h> and <inttypes.h> for c.h integers.
- 962da900ac8f 18.0 landed
Remove traces of BeOS.
- a2d9a9b95ad9 18.0 landed
More correct way to check for existence of types, which allows to specify
- 15abc7788e66 7.2.1 cited