Re: INT64_FORMAT in translatable strings - Mailing list pgsql-hackers
From | Kyotaro Horiguchi |
---|---|
Subject | Re: INT64_FORMAT in translatable strings |
Date | |
Msg-id | 20210423.094309.606035299195728411.horikyota.ntt@gmail.com Whole thread Raw |
In response to | Re: INT64_FORMAT in translatable strings (Tom Lane <tgl@sss.pgh.pa.us>) |
List | pgsql-hackers |
At Thu, 22 Apr 2021 09:29:46 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in > Julien Rouhaud <rjuju123@gmail.com> writes: > > On Thu, Apr 22, 2021 at 07:49:23PM +0900, Michael Paquier wrote: > >> May I ask why you are using "unsigned long long int" rather uint64? > > > My understanding is that it's the project standard. See e.g. > > https://www.postgresql.org/message-id/1730584.1617836485@sss.pgh.pa.us > > Indeed, using %lld, %llu, etc with a matching cast to "long long" or > "unsigned long long" is the approved way. Don't use [u]int64 because > that does not necessarily match these format specs. It's probably > physically compatible, but that won't stop pickier compilers from > nagging about a format mismatch. > > But what I thought Michael was griping about is the use of "int", > which is a noise word here. Either "long long int" or "long long" > will work, but I think we've preferred the latter because shorter. Yeah, there's no reason for the "int" other than just following the immediate preceding commit 3286065651. I also prefer the shorter notations. Attached. regards. -- Kyotaro Horiguchi NTT Open Source Software Center From 8a4dddaaca59339ea69019c4d1d9c8a8481a7768 Mon Sep 17 00:00:00 2001 From: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Date: Wed, 21 Apr 2021 19:50:43 +0900 Subject: [PATCH v2] Don't use INT64_FORMAT inside message strings, take 2 Use %lld/%llu instead of (U)INT64_FORMAT. Nowadays our standard way of printing int64 uint64 values at least in translatable strings is using the conversion specifications "%lld" and "%llu" and explicitly casting the parameters into "long long" and "unsigned long long" respectively. Along with that, we prefer to use "long" than "long int". See commit 595a0eab7f425e3484639fae1f7e221fe9c2651a. --- contrib/pg_prewarm/pg_prewarm.c | 8 ++++---- src/backend/access/transam/xlogprefetch.c | 23 +++++++++++------------ src/bin/pgbench/pgbench.c | 6 +++--- 3 files changed, 18 insertions(+), 19 deletions(-) diff --git a/contrib/pg_prewarm/pg_prewarm.c b/contrib/pg_prewarm/pg_prewarm.c index a855452936..48d0132a0d 100644 --- a/contrib/pg_prewarm/pg_prewarm.c +++ b/contrib/pg_prewarm/pg_prewarm.c @@ -126,8 +126,8 @@ pg_prewarm(PG_FUNCTION_ARGS) if (first_block < 0 || first_block >= nblocks) ereport(ERROR, (errcode(ERRCODE_INVALID_PARAMETER_VALUE), - errmsg("starting block number must be between 0 and " INT64_FORMAT, - nblocks - 1))); + errmsg("starting block number must be between 0 and %lld", + (long long) (nblocks - 1)))); } if (PG_ARGISNULL(4)) last_block = nblocks - 1; @@ -137,8 +137,8 @@ pg_prewarm(PG_FUNCTION_ARGS) if (last_block < 0 || last_block >= nblocks) ereport(ERROR, (errcode(ERRCODE_INVALID_PARAMETER_VALUE), - errmsg("ending block number must be between 0 and " INT64_FORMAT, - nblocks - 1))); + errmsg("ending block number must be between 0 and %lld", + (long long) (nblocks - 1)))); } /* Now we're ready to do the real work. */ diff --git a/src/backend/access/transam/xlogprefetch.c b/src/backend/access/transam/xlogprefetch.c index 9a6f17ca36..ae4585232b 100644 --- a/src/backend/access/transam/xlogprefetch.c +++ b/src/backend/access/transam/xlogprefetch.c @@ -358,20 +358,19 @@ XLogPrefetcherFree(XLogPrefetcher *prefetcher) /* Log final statistics. */ ereport(LOG, (errmsg("recovery finished prefetching at %X/%X; " - "prefetch = " UINT64_FORMAT ", " - "skip_hit = " UINT64_FORMAT ", " - "skip_new = " UINT64_FORMAT ", " - "skip_fpw = " UINT64_FORMAT ", " - "skip_seq = " UINT64_FORMAT ", " + "prefetch = %llu, " + "skip_hit = %llu, " + "skip_new = %llu, " + "skip_fpw = %llu, " + "skip_seq = %llu, " "avg_distance = %f, " "avg_queue_depth = %f", - (uint32) (prefetcher->reader->EndRecPtr << 32), - (uint32) (prefetcher->reader->EndRecPtr), - pg_atomic_read_u64(&SharedStats->prefetch), - pg_atomic_read_u64(&SharedStats->skip_hit), - pg_atomic_read_u64(&SharedStats->skip_new), - pg_atomic_read_u64(&SharedStats->skip_fpw), - pg_atomic_read_u64(&SharedStats->skip_seq), + LSN_FORMAT_ARGS(prefetcher->reader->EndRecPtr), + (unsigned long long) pg_atomic_read_u64(&SharedStats->prefetch), + (unsigned long long) pg_atomic_read_u64(&SharedStats->skip_hit), + (unsigned long long) pg_atomic_read_u64(&SharedStats->skip_new), + (unsigned long long) pg_atomic_read_u64(&SharedStats->skip_fpw), + (unsigned long long) pg_atomic_read_u64(&SharedStats->skip_seq), SharedStats->avg_distance, SharedStats->avg_queue_depth))); hash_destroy(prefetcher->filter_table); diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c index da1d9ec535..0827665997 100644 --- a/src/bin/pgbench/pgbench.c +++ b/src/bin/pgbench/pgbench.c @@ -5359,8 +5359,8 @@ parseScriptWeight(const char *option, char **script) } if (wtmp > INT_MAX || wtmp < 0) { - pg_log_fatal("weight specification out of range (0 .. %u): " INT64_FORMAT, - INT_MAX, (int64) wtmp); + pg_log_fatal("weight specification out of range (0 .. %u): %lld", + INT_MAX, (long long) wtmp); exit(1); } weight = wtmp; @@ -5680,7 +5680,7 @@ set_random_seed(const char *seed) } if (seed != NULL) - pg_log_info("setting random seed to " UINT64_FORMAT, iseed); + pg_log_info("setting random seed to %llu", (unsigned long long) iseed); random_seed = iseed; /* Fill base_random_sequence with low-order bits of seed */ -- 2.27.0
pgsql-hackers by date: