[Toybox] [PATCH] Add "df -i".

[enh]

On Fri, Nov 17, 2017 at 8:39 AM, Rob Landley <rob at landley.net> 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.