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

Previous Next

Full log

Message #19 received at 56710 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 56710 <at> debbugs.gnu.org, schwab <at> linux-m68k.org
Subject: Re: bug#56710: ls vs. stat display of st_size
Date: Sun, 24 Jul 2022 09:48:11 +0100

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

Previous Next

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