public inbox for [email protected]  
help / color / mirror / Atom feed
From: Peter Eisentraut <[email protected]>
To: Thomas Munro <[email protected]>
To: Tom Lane <[email protected]>
Cc: [email protected]
Subject: Re: pread, pwrite, etc return ssize_t not int
Date: Fri, 1 Mar 2024 15:12:40 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+hUKGJaCxLhNxAFUJZ0QYSfqovq7TbVV+6YGPrvSa-G7ODWow@mail.gmail.com>
References: <[email protected]>
	<CA+hUKG+Y1xfDjaXmH5g07VitPN+-Wfp3P9RumNgD6jJXzm5Hrg@mail.gmail.com>
	<CA+hUKGJaCxLhNxAFUJZ0QYSfqovq7TbVV+6YGPrvSa-G7ODWow@mail.gmail.com>

On 27.02.24 12:21, Thomas Munro wrote:
> Patches attached.
> 
> PS Correction to my earlier statement about POSIX: the traditional K&R
> interfaces were indeed in the original POSIX.1 1988 but it was the
> 1990 edition (approximately coinciding with standard C) that adopted
> void, size_t, const and invented ssize_t.

0001-Return-ssize_t-in-fd.c-I-O-functions.patch

This patch looks correct to me.

0002-Fix-theoretical-overflow-in-Windows-pg_pread-pg_pwri.patch

I have two comments on that:

For the overflow of the input length (size_t -> DWORD), I don't think we 
actually need to do anything.  The size argument would be truncated, but 
the callers would just repeat the calls with the remaining size, so in 
effect they will read the data in chunks of rest + N * DWORD_MAX.  The 
patch just changes this to chunks of N * 1GB + rest.

The other issue, the possible overflow of size_t -> ssize_t is not 
specific to Windows.  We could install some protection against that on 
some other layer, but it's unclear how widespread that issue is or what 
the appropriate fix is.  POSIX says that passing in a size larger than 
SSIZE_MAX has implementation-defined effect.  The FreeBSD man page says 
that this will result in an EINVAL error.  So if we here truncate 
instead of error, we'd introduce a divergence.







view thread (4+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: pread, pwrite, etc return ssize_t not int
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox