Subject: Re: bug#56710: ls vs. stat display of st_size

From: Paul Eggert <[email-masked]>
Date: Sun, 24 Jul 2022 09:18:45 -0700

On 7/24/22 01:48, Pádraig Brady wrote:

> 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

I vaguely recall being involved with that decades-old change. The POSIX 
requirement is here:

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html#tag_20_73_10

(look for "%u").

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

I don't see why; negative sizes sort just as well as positive ones do.

> 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.

Consistency is reasonably important here (as per the original bug 
report), so if those are the choices let's leave things as-is.