Re: stat signed/unsigned

[Paul Eggert]

Pádraig Brady <address@hidden> writes:

>> It's guaranteed that st_size's type is signed, since off_t is signed.
>
> What I meant is that it assumes that st_size will never overflow.

POSIX allows st_size to have negative values for files that are neither
regular files nor symbolic links, and I don't think coreutils should
assume that these negative values necessarily represent overflow.

I'm leery of assuming that st_blksize should be interpreted as an
unsigned value.  If it's (say) -1, and we interpret it as (say) 2**64 -
1, we're likely to crash with a memory allocation issue.

I'm leery of using 'unsigned int' values to store print widths used by
'printf'.  The C standard says they're supposed to be 'int'.  Keeping
them 'int' is more likely to catch overflow bugs (if compiled with
arithmetic overflow checking turned on, admittedly unlikely....).

Better than using 'assert', 'du' should report a size overflow and
continue.

I'm with Jim that we shouldn't contort the code merely to pacify GCC's
overly enthusiastic sign compare warnings.

Gotta run, but these are my thoughts for now....