Date: Mon, 18 Jan 2010 04:00:21 GMT From: Bruce Evans <brde@optusnet.com.au> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/142911: [patch] vmstat(8) -w should produce error message if fed a negative value Message-ID: <201001180400.o0I40LGM035334@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/142911; it has been noted by GNATS. From: Bruce Evans <brde@optusnet.com.au> To: "Efstratios Karatzas <gpf.kira@gmail.com>" <gpf.kira@gmail.com> Cc: freebsd-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: bin/142911: [patch] vmstat(8) -w should produce error message if fed a negative value Date: Mon, 18 Jan 2010 14:55:41 +1100 (EST) On Sun, 17 Jan 2010, Efstratios Karatzas <gpf.kira@gmail.com> wrote: >> Description: > vmstat(8) -w should produce an error message and exit when fed a negative numerical value or a non numerical value at all, in which case atoi simply returns 0. This is the way iostat(8) handles this situation. > > If we do not check for a negative value, then the negative value we are fed becomes an extremely large unsigned int and the thread will sleep(3) for a long time indeed. Please use line lengths of considerably less than 168 characters. I'm editing this with a slightly wrong $TERMCAP and the line wrap from the long lines is even more horrible than usual. There is another bad atoi() for the wait interval, in the BACKWARD_COMPATIBILITY ifdef, which is a non-optional option. There are other bad atoi()s in the file. One has a bounds check and neither has a type error to break negative values. >> Fix: > apply my patch, all we need is a simple check if the value is less than 1. This way an error message also occurs if we could not parse a number, since the return value in that case is 0. -w 0 used to sort of work -- it was equivalent to not specifying an interval. Maybe some scripts or fingers depend on this. Probably lots still depends on the undocumented BACKWARD_COMPATIBILITY behaviour (vmstat 1 == vmstat -w 1), so this non-optional option can never be removed. The other bad atoi()s don't use this trick, so they give a garbage result for parse errors. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201001180400.o0I40LGM035334>