[Toybox] Do you suppose this du -b patch is worth it?

[enh]

On Wed, Dec 11, 2019 at 11:41 AM Rob Landley <rob at landley.net> wrote:
>
>
>
> On 12/10/19 6:47 PM, enh wrote:
> > if i saw someone trying to use that, i'd assume that they were digging
> > themselves into an unnecessary hole... in fact, the only time i
> > remember seeing anyone try to use --apparent-size we talked them out
> > of it.
> >
> > that said --- du tests that used --apparent-size would probably work
> > on all kinds of filesystems that the current tests don't work on.
>
> $ stat -c%s toys.h
> 3440

yeah, i was thinking yesterday that even if you did want `du -b` as a
"show me the size in bytes, a tab, and the filename of all files",
that's just

  find . -type f -printf "%s\t%p\n"

which toybox already does just fine.

> > (so
> > maybe implementing --apparent-size and -B# wouldn't be so silly, and
> > then -b could just turn those on?)
>
> "Is this one simple option worth it?"
>
> "You could add two more options to justify this one."
>
> I'll take that as a no.

mission accomplished!

> > i'm assuming the busybox request didn't come with a convincing use case?
>
> No, but I was using it as an indicator that somebody somewhere missed its absence.

like i said, the only time i've seen anyone try to go down this route,
they were holding it wrong :-)

> > (there are still Android devices with *only* 32-bit userspace.
> > everything low-end is that, even though there are no 32-bit SoCs, and
> > afaik everyone's using a 64-bit *kernel* at least.)
>
> Indeed. The x32 target was created because smaller pointer sizes mean less stack
> space and better CPU cache and memory bus bandwidth utilization.
>
> And in the embedded space, 32 bits is often a luxury. (One of our taglines for
> j-core is "32 bits for the price of 8", although "price" here is circuitry size
> in your design. We'd need waaaaaaay more volume to get the costs down to "3 cent
> chip" territory.)
>
> Rob