Re: truncating casts of pgoff_t
Chao Li <li.evan.chao@gmail.com>
From: Chao Li <li.evan.chao@gmail.com>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2026-06-22T09:29:10Z
Lists: pgsql-hackers
> On Jun 22, 2026, at 15:56, Peter Eisentraut <peter@eisentraut.org> wrote: > > I found a couple of places where a pgoff_t value, typically a signed 64-bit integer, is cast to a type with a smaller range. I noticed this specifically in error messages, so it's mostly cosmetic. Also, files with a size where this would matter are not expected in many places, but I suspect that the case in basebackup_server.c in the attached patch can actually happen. > > The fix is to use the %lld print format and a cast to long long int, which is the style already in most places. > > In passing, I also converted a few places that used %llu to print pgoff_t to also use %lld instead. This is mostly for consistency, but it also feels more robust in case a negative value ever sneaks in. > <0001-Don-t-cast-pgoff_t-to-possibly-32-bit-types-for-outp.patch><0002-Print-off_t-pgoff_t-consistently-as-lld.patch> I have small comment: walsender.c ``` + /* XXX might truncate histfilelen */ + Assert(histfilelen <= UINT32_MAX); ``` histfilelen is returned from lseek(), that’s a runtime behavior. I’m afraid Assert is weak here. If we really worry about the truncate, should we use elog(ERROR). Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/
Commits
-
Don't cast off_t to 32-bit type for output, bug fix
- c754d9311509 15 (unreleased) landed
- 67235209ca05 16 (unreleased) landed
- 4d99e6ed640e 17 (unreleased) landed
- 215ab56119e0 18 (unreleased) landed
- d4e2280b7e48 19 (unreleased) landed
- e8f851d61727 master landed