Date: Sat, 11 May 2013 01:53:34 -0400 From: Eitan Adler <eadler@freebsd.org> To: Benjamin Kaduk <bjkfbsd@gmail.com> Cc: "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org> Subject: Re: svn commit: r250432 - head/usr.bin/split Message-ID: <CAF6rxgkO7org=6utK5UZMhUA9qOMkuNZ_%2Bed7nk20owa%2BykrGQ@mail.gmail.com> In-Reply-To: <CAJ5_RoB=hn1bHeqqUyvJWeJqooB6QwLFov=LtNu4PaYpsfMLQg@mail.gmail.com> References: <201305100423.r4A4N44u094726@svn.freebsd.org> <CAJ5_RoB=hn1bHeqqUyvJWeJqooB6QwLFov=LtNu4PaYpsfMLQg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10 May 2013 13:05, Benjamin Kaduk <bjkfbsd@gmail.com> wrote: > This check relies on signed integer overflow, which is undefined behavior. > Furthermore, even if one assumes a non-evil compiler and two's complement > representation, this check fails for pattlen == 10. > 10**9 is representable as both a signed and unsigned 32-bit integer, but > 10**10 overflows both variants and ends up in the positive side of the > signed space. > > With a fixed number of bases to be exponentiated here (10 or 26), it would > seem much simpler to do the logarithm manually out-of-band and just hardcode > a check on sufflen (noting that maxfiles is of type long which can be either > 32 or 64 bits). ... Good point. I did not look closely at this code and assumed it was correct. I shall fix it. -- Eitan Adler Source, Ports, Doc committer Bugmeister, Ports Security teams
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAF6rxgkO7org=6utK5UZMhUA9qOMkuNZ_%2Bed7nk20owa%2BykrGQ>