<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Aug 9, 2021 at 12:26 AM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Sorry for the delay, I have a _really_ bad cold.<br>
<br>
On 8/7/21 7:11 AM, Samanta Navarro wrote:<br>
> The functions readall and writeall can return an error value by mistake<br>
> if more than 2 GB of data are read or written.<br>
<br>
That was intentional. If your file sizes are that big we probably want to mmap()<br>
stuff. Single atomic transactions greater than 2 gigabytes are probably a bad<br>
idea from a latency standpoint (circa 2015 kernel used to hold locks across<br>
these, probably fixed now but I haven't checked) and mallocing buffers that big<br>
is probably also a bad idea. (I hit a glibc version that wouldn't allow a malloc<br>
greater than 128 megs, haven't tested recently...)<br>
<br>
That said, I'd want it to hard error rather than integer overflow back into a<br>
sane value (6 gigs being treated as 2...)<br>
<br>
> This happens because int and ssize_t are of different sizes on 64 bit<br>
> architectures. Using ssize_t resolves the issue because read and write<br>
> return ssize_t already.<br>
<br>
Actually on 32 bit Linux architectures ssize_t is also long long because "large<br>
file support" was introduced over 20 years ago:<br>
<br>
<a href="https://static.lwn.net/1999/0121/a/lfs.html" rel="noreferrer" target="_blank">https://static.lwn.net/1999/0121/a/lfs.html</a><br>
<br>
And 5 years later even 2 terabytes was limiting:<br>
<br>
<a href="https://lwn.net/Articles/91731/" rel="noreferrer" target="_blank">https://lwn.net/Articles/91731/</a><br>
<br>
So if we're changing the type it should change to long long, but this is really<br>
pilot error in the callers. (That said, readfd() and lskip() are making this<br>
mistake, so there needs to _be_ an enforcement mechanism...)<br>
<br>
Rob<br>
<br>
P.S. One of my most unsolvable todo items is what to do about readline() on<br>
/dev/zero. If it's looking for /n it's just gonna allocate a bigger and bigger<br>
buffer until it triggers the OOM killer. If a single line IS a gigabyte long,<br>
what am I supposed to _do_ about it?<br></blockquote><div><br></div><div>nothing? seems like toybox should just do what was asked, not least because whether a gigabyte is large or small is a matter of opinion? (he says, still deeply scarred by all the Bell Labs boys' fixed-length buffers... i had to use _perl_ because of them! PERL!)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
_______________________________________________<br>
Toybox mailing list<br>
<a href="mailto:Toybox@lists.landley.net" target="_blank">Toybox@lists.landley.net</a><br>
<a href="http://lists.landley.net/listinfo.cgi/toybox-landley.net" rel="noreferrer" target="_blank">http://lists.landley.net/listinfo.cgi/toybox-landley.net</a><br>
</blockquote></div></div>