aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils
diff options
context:
space:
mode:
authorThomas Munro <tmunro@postgresql.org>2024-03-02 11:59:34 +1300
committerThomas Munro <tmunro@postgresql.org>2024-03-02 12:09:28 +1300
commit653b55b57081dc6fb8c75d61870c5fdc8c8554cc (patch)
treef2ac89b0d1c272ec40ad13846d9a32b76bd5530b /src/backend/utils
parent655dc310460c601d434d05339b7fa46ed97675b3 (diff)
downloadpostgresql-653b55b57081dc6fb8c75d61870c5fdc8c8554cc.tar.gz
postgresql-653b55b57081dc6fb8c75d61870c5fdc8c8554cc.zip
Return ssize_t in fd.c I/O functions.
In the past, FileRead() and FileWrite() used types based on the Unix read() and write() functions from before C and POSIX standardization, though not exactly (we had int for amount instead of unsigned). In commit 2d4f1ba6 we changed to the appropriate standard C types, just like the modern POSIX functions they wrap, but again not exactly: the return type stayed as int. In theory, a ssize_t value could be returned by the underlying call that is too large for an int. That wasn't really a live bug, because we don't expect PostgreSQL code to perform reads or writes of gigabytes, and OSes probably apply internal caps smaller than that anyway. This change is done on the principle that the return might as well follow the standard interfaces consistently. Reported-by: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Peter Eisentraut <peter@eisentraut.org> Discussion: https://postgr.es/m/1672202.1703441340%40sss.pgh.pa.us
Diffstat (limited to 'src/backend/utils')
0 files changed, 0 insertions, 0 deletions