<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 8, 2021 at 12:10 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">Many moons ago, trying to determine the size of a CD in a cdrom drive was a<br>
pain, and the "binary search for last location we can actually read" was the<br>
only reliable way to determine the length of the image I could find.<br>
<br>
But I'm not sure that's still relevant? </blockquote><div><br></div><div>yeah, i've assumed that that's dead code too...</div><div><br></div><div>in situations like this, i always remove the code --- that way i've either removed some superstition from the world, which is always a good thing, or i'll have a useful and up-to-date comment to add to the code when reality forces me to revert my change, which is also always a good thing for code that had people scratching their heads asking "is this really necessary?".</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">That hardware's mostly gone away. DVD<br>
drives are still around, but require a ritual sacrifice in order to read the<br>
actual image data with that whole decss nonsense to <strike>remove the style<br>
sheet</strike> unscramble the contents, and while burning your own DVD for<br>
backup CLAIMS to have a half life of 5 years mine were more like 3, which ain't<br>
great for data retention, which was a widely known problem at least a decade ago<br>
ala<br>
<a href="https://www.rlvision.com/blog/how-long-do-writable-cddvd-last-400-discs-put-to-the-test/" rel="noreferrer" target="_blank">https://www.rlvision.com/blog/how-long-do-writable-cddvd-last-400-discs-put-to-the-test/</a><br>
so people just bought USB hard drives and stuck them in a safe deposit box if<br>
they cared... Ahem. Anyway:<br>
<br>
Doing stat() to find a length, the "get block device size" ioctl, and finally<br>
lseek(SEEK_END) is _probably good enough? I can still fall back to the binary<br>
search but I'm not sure how SEEK_END is going to return failure and yet SEEK_SET<br>
still work in that binary search case? (The CD didn't even spin up the drive for<br>
the checks that didn't actually try to read data, because spinning up the drive<br>
was expensive so they disabled it and stubbed out the return values. This was<br>
related to the scsi layer throwing all the devices into a big pile and giving it<br>
a stir so /dev/sd? devices never enumerated in a known order the way IDE had<br>
because if the IBM zseries was going to have a serious device enumeration<br>
problem then all those IBM Linux developers Sam Palmisano was spending $1<br>
billion/year on from 2001-2005 were going to inflict that problem on the Linux<br>
on the Desktop crowd until there were no more people trying to use Linux on the<br>
Desktop. And thus was systemd forged in the fires of Mt Doom, and short of<br>
hiring Peter Dinklage to throw a recording of the song "bananaphone" into<br>
Kilauea nobody has a plan to make it go away again. Where was I?)<br>
<br>
The other thing is that fdlength() currently returns 0 when it can't find the<br>
length, and off_t is signed* and 0 is a valid length so it SHOULD return -1<br>
(with an xfdlength exiting), </blockquote><div><br></div><div>(weird. i was sure i'd noticed this before and looked at adding xfdlength(), but i can't find the git clone now ... too many machines! this is not the future NFS promised us!)</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">but I need to audit the callers:<br>
<br>
load_policy: xmmap(0) will barf, eh, close enough?<br>
<br>
ftpget: storing the return value in unsigned long long. Can't check.<br>
<br>
hexedit: checking <1 for bad length, should be fine.<br>
<br>
mkswap: no check, int underflow for 0 length file (unsigned pages = 0-1) so it<br>
would write a corrupted header... to a zero length file you couldn't mount anyway?<br>
<br>
modinfo: storing into a signed 32 bit int. Not that people are going to load a<br>
single module larger than 2 gigabytes but still... Then feeds length to xmmap()<br>
which would die on <0.<br>
<br>
shred: stores in off_t (signed long), checks for <1<br>
<br>
truncate: stores in a signed variable, no check, negative length in ftruncate()<br>
would be EINVAL.<br>
<br>
mkdev, mke2fs, modprobe, vi are all in pending.<br>
<br>
Rob<br>
<br>
* glibc defines off_t as __off_t which is __OFF_T_TYPE which is<br>
__SYSCALL_SLONG_TYPE which is __SLONGWORD_TYPE which is long int. The<br>
<strike>aristocrats</strike> FSF!<br>
_______________________________________________<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>