| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> |
| Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Bryan Green <dbryan(dot)green(at)gmail(dot)com> |
| Subject: | Re: Switch buffile.c/h to use pgoff_t |
| Date: | 2025-12-24 23:42:04 |
| Message-ID: | aUx6TMczfmwyv_h3@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Dec 24, 2025 at 05:01:57PM +0800, Chao Li wrote:
> Make sense, bytestowrite is not a file offset. So, in the current code,
> availbytes is not a file offset either, but it is defined as pgoff_t, which
> has the same confusion, right? Also bytestowrite is casted to pgoff_t, it's
> the same confusion again.
Yeah, actually this suggestion makes more sense. availbytes is a
computation made of a maximal size and an offset, so defining it as an
offset from the start is kind of weird.
Now I don't think that your suggested set of changes could become more
consistent with a few more changes. For example, what about pos and
nbytes in BufFile? While ssize_t is more consistent with FileRead()
and FileWrite(), this code is written to care about signedness while
ssize_t has a stricter range per posix, hence could int64 be a better
choice for the whole interface? int64 is already what we use for
BufFileSize(), which is due to the limit of MAX_PHYSICAL_FILESIZE of
course.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2025-12-24 23:45:20 | Re: Switch buffile.c/h to use pgoff_t |
| Previous Message | Chao Li | 2025-12-24 23:37:54 | Re: Docs: Standardize "cannot" usage in SGML source |