On Sat, May 10, 2014 at 11:42 AM, Paul Eggert <egg...@cs.ucla.edu> wrote: > * src/shred.c (main): Limit -n (number of passes) value to > ULONG_MAX, not to UINT32_MAX, since the vars are unsigned long. > Limit the -s (file size) value to OFF_T_MAX. > --- > src/shred.c | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/src/shred.c b/src/shred.c > index 607c6be..f4347e0 100644 > --- a/src/shred.c > +++ b/src/shred.c ... > @@ -1256,9 +1256,10 @@ main (int argc, char **argv) > > case 's': > { > - uintmax_t tmp; > - if (xstrtoumax (optarg, NULL, 0, &tmp, "cbBkKMGTPEZY0") > - != LONGINT_OK) > + intmax_t tmp; > + if ((xstrtoimax (optarg, NULL, 0, &tmp, "cbBkKMGTPEZY0") > + != LONGINT_OK) > + || OFF_T_MAX < tmp)
Hi Paul, The above makes it so shred now accepts a negative size. Before, that would be diagnosed as invalid: $ shred -s-1 k shred: -1: invalid file size With a size of -2, shred will write 64KB blocks forever -- or until it runs out of space. Here's a patch to fix that and to add a test covering that case:
0001-shred-don-t-infloop-upon-negative-size.patch
Description: Binary data