GNU bug report logs - #56710
ls vs. stat display of st_size

Previous Next

Package: coreutils;

Reported by: Andreas Schwab <schwab <at> linux-m68k.org>

Date: Fri, 22 Jul 2022 20:10:02 UTC

Severity: normal

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: 56710 <at> debbugs.gnu.org, eggert <at> cs.ucla.edu, schwab <at> linux-m68k.org
Subject: bug#56710: ls vs. stat display of st_size
Date: Sat, 23 Jul 2022 13:17:38 +0100
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




This bug report was last modified 2 years and 355 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.