[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: stat signed/unsigned

From: Paul Eggert
Subject: Re: stat signed/unsigned
Date: Thu, 08 Jan 2009 10:57:31 -0800
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux)

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]