Re: Replace some %llu remnants in the tree

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: Replace some %llu remnants in the tree
Date: 2025-06-11 07:58:00
Message-ID: 69907b1e-4abd-45de-ba26-a1f9708f13e9@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 09.06.25 05:59, Michael Paquier wrote:
> While hacking a different patch, I've noticed that a couple of %llu
> did not get the PRIu64 call in the AIO code, and I don't see why we
> could not switch them. These have been introduced in commits that got
> into the tree after Peter's 15a79c73111f.

Looks good.

> That's not necessarily mandatory for v18, for sure, but as this is new
> code we could as well clean it up before forking the next stable
> branch.

Agree this should go into v18.

> A couple remain even after the attached, which have been left off by
> Peter for the same reasons as the ones I am guessing here:
> - launch_backend.c for paramHandle, does not seem worth it.

According to Microsoft documentation, LONG_PTR is __int64, and so using
PRId64 would seem to be appropriate. However, I wonder whether it
wouldn't be simpler to print the original paramHandle either as %p or
cast to uintptr_t, to avoid having two separate code paths.

> - ecpglib/execute.c, when storing some input, which does not seem
> worth bothering either.

These are dealing with actual long long int values, to using %lld/%llu
seems appropriate.

> - reconstruct.c, offset handling.
> - pg_backup_tar.c, ftello() result and some consistency with the
> surroundings.
> - pg_verifybackup.c and astreamer_verify.c, for Sizes.

These are using off_t or pg_off_t, for which there is no format
placeholder, so you have to cast it to something.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Xuneng Zhou 2025-06-11 07:58:26 Re: Proposal: Limitations of palloc inside checkpointer
Previous Message Peter Eisentraut 2025-06-11 07:43:59 Re: Fix potential overflow risks from wcscpy and sprintf