bug#56710: ls vs. stat display of st_size

[Pádraig Brady]

On 23/07/2022 21:07, Paul Eggert wrote:
> On 7/23/22 05:17, Pádraig Brady wrote:
>
> > BTW I see we've code in cache_fstatat() that assumes
> > st_size can't have such large values, which contradicts a bit.
>
> Good catch. I installed the first attached patch.
>
>
>   > This is only a real consideration for virtual files I think
>   > since off_t is signed, and so impractical for a real file system
>   > to support files > OFF_T_MAX.
>
> Yes, that sounds right.
>
> You've convinced me that 'ls' should switch to the way 'stat' behaves
> rather than vice versa; that's more useful anyway. How about the
> attached second patch, which I haven't installed? (I was actually
> inclined this way originally but got lazy.)

Well ls(1) was explicitly changed to assuming only positive,
citing POSIX (though I can't see it in POSIX myself):
https://github.com/coreutils/coreutils/commit/67ba4ac01

Also ls(1) can sort by size, which gives a little more
credence to assuming positive only size.

Also ls(1) is a bit higher level, more human facing than stat(1).

For these reasons I would keep ls(1) as is (assuming positive).

As for stat(1), it's now consistent with ls(1) which has some benefit.
It is lower level though, so in my mind it might be better
to output the raw value, especially since it's such an edge case.

So I'd leave ls(1) as is, and I'll leave it up to you
how to handle stat(1) given the above points.

cheers,
Pádraig