On 10/18/2019 10:54 AM, Denys Vlasenko wrote:
On Thu, Oct 10, 2019 at 4:35 PM Martin Lewis <[email protected]> wrote:
Hello,
Could you please elaborate on what was lacking in the INT_MAX part?
As seen in write's man page:
On Linux, write() (and similar system calls) will transfer at most 0x7ffff000
(2,147,479,552) bytes, returning the number of bytes actually transferred.
(This is true on
both 32-bit and 64-bit systems.)
Wouldn't it create an issue with 64 bit systems when trying to
read/write large files?
This seemed like a change not prompted by an actually observed
buggy behavior.
In fact, to my eyes
+ if (count > SYS_BUFSIZE_MAX)
+ count = SYS_BUFSIZE_MAX;
looks like it *introduces* a bug. read() is always allowed to return a short
count however the kernel pleases, and safe_read is supposed to call it in a
loop until the desired size is reached or until EOF or a fatal error. If you
truncate the count before beginning the loop, then the caller ends up with a
short read even though there might be more data. (not that anyone would likely
have a reason to *require* more than 2GB in a single buffer anyway...)
-Mike
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
