Pádraig Brady <[email protected]> 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.... _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
