On Fri, Nov 17, 2017 at 8:39 AM, Rob Landley <[email protected]> wrote: > On 11/15/2017 03:11 PM, enh wrote: >> Also switch to u64 for calculations. Some FUSE file systems have inode >> counts large enough to overflow s64. > > 1<<63 = 9,223,372,036,854,775,808 = 9.2 quintillion. > > That's kind of disturbing. (What does the filesystem have 9.2 > quintillion _of_?)
looking at file systems in the kernel tree it seems like there's some disagreement about whether to represent "unlimited" by a 0 or the largest possible number. for this *particular* file system, it looks like a bug... they used 1<<31, which becomes negative, but gets assigned to an unsigned field and passed to the kernel which interprets it as unsigned. but it seemed to me that our interpretation should match the kernel's, practically meaningless though it is. > Are we going to have a serious need for 128 bit numbers soon? If so, > where does "long long" move to? LP64 only guarantees it's at _least_ 64 > bits... all Google/Android code should explicitly say int64_t or whatever anyway. "long" in particular causes too much confusion when folks who grew up with LP64 suddenly have their code run on LP32, though there's no getting away from size_t. there are a few `__uint128_t`s around already, but the ones i know of are all for integer representations of SIMD registers. > Patch applied. The first [-blah] in the usage line collates the short > options without arguments and -i takes no argument so I'm collating it. ah, i've always assumed they were grouped by meaning. the existing options were all about units, and this was about _what_, so i kept them separate. > And using a ? : operator on the two printf() strings with the same > arguments. > > Why are you going out of your way to force block to be signed? i think no better reason than that i touched that code before i noticed the unsigned problem, and then didn't uniformly fix it. > (Can the > number of blocks be negative? Percent is an unsigned long long for a > 1-100 range because that way there's one list of variable declarations, > might as well throw block in there. And you left percent as %lld instead > of %llu while changing the type, not that it matters but as long as I'm > there...) POSIX does say that blksize_t is signed (!), but fsblkcnt_t is unsigned. > Rob -- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ Android native code/tools questions? Mail me/drop by/add me as a reviewer. _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
