Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 22 May 2016 16:26:34 -0700
From:      Conrad Meyer <cem@FreeBSD.org>
To:        Dirk Engling <erdgeist@erdgeist.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org>
Subject:   Re: read(2) and thus bsdiff is limited to 2^31 bytes
Message-ID:  <CAG6CVpWbYTBQCVQ5Eu576Tx6%2Bvd03RskkcF8UemVNeq%2BVF8Mvg@mail.gmail.com>
In-Reply-To: <20160522231048.GA25503@britannica.bec.de>
References:  <b2515cae-b75d-66e9-4207-3cf100ab3ab0@erdgeist.org> <CAG6CVpWb7nvX%2BLFpLizkSx8Y-deXfXiWi=rL56iGZ71YPhmLbw@mail.gmail.com> <20160522231048.GA25503@britannica.bec.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, May 22, 2016 at 4:10 PM, Joerg Sonnenberger <joerg@bec.de> wrote:
> On Sun, May 22, 2016 at 03:56:33PM -0700, Conrad Meyer wrote:
>> ERRORS
>>      The read(), readv(), pread() and preadv() system calls will succeed
>>      unless:
>> ...
>>      [EINVAL]           The value nbytes is greater than INT_MAX.
>>
>> It does seem silly to me given nbytes is a size_t.  I think it should
>> error if nbytes is greater than SSIZE_T_MAX, but on platforms where
>> size_t is larger than int (e.g. amd64) it shouldn't error for nbytes
>> in [INT_MAX, SSIZE_T_MAX - 1].
>
> There are a lot of valid reasons for not doing arbitrarily large
> operations, especially since a certain amount of atomicity is expected
> for local IO. That doesn't mean that it can't be turned into a short
> read/write instead. Erroring out seeems completely unjustified.

Sure; those reasons also apply to INT_MAX-sized IOs (2 GB).

Conrad



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpWbYTBQCVQ5Eu576Tx6%2Bvd03RskkcF8UemVNeq%2BVF8Mvg>