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.
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 |