[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#56710: ls vs. stat display of st_size
From: |
Pádraig Brady |
Subject: |
bug#56710: ls vs. stat display of st_size |
Date: |
Sat, 23 Jul 2022 13:17:38 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:98.0) Gecko/20100101 Thunderbird/98.0 |
On 22/07/2022 21:52, Paul Eggert wrote:
Thanks for reporting that. I installed the attached.
Playing devil's advocate, this takes the stance that
st_size should always be treated as unsigned
(given that stat(1) is a lower level util than ls(1)).
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.
In this case /proc/kcore is a virtual file, with the
size representing the VM size (guessing riscv64 in this case).
But other virtual files may set st_size = -1,
to represent an unknown file size, which with the change,
scripts using stat(1) can no longer rely on?
Perhaps the "-1" case could be specialized for this.
BTW I see we've code in cache_fstatat() that assumes
st_size can't have such large values, which contradicts a bit.
BTW assuming that st_size is unsigned, reminds me of this change where
we cast all st_size to unsigned, which also allowed us to enable -Wsign-compare:
https://lists.gnu.org/archive/html/bug-coreutils/2009-01/msg00050.html
cheers,
Pádraig