Date: Tue, 3 Jan 2017 18:04:02 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Ian Lepore <ian@freebsd.org> Cc: Pedro Giffuni <pfg@FreeBSD.org>, Conrad Meyer <cem@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r311109 - head/usr.bin/patch Message-ID: <20170103160401.GT1923@kib.kiev.ua> In-Reply-To: <1483458723.16152.107.camel@freebsd.org> References: <201701021823.v02INWXc028047@repo.freebsd.org> <CAG6CVpUUFoTZBO0Ja2aSn%2BeMi_BO0u131YKQ1yQumu%2BdRhVY3A@mail.gmail.com> <aa9172cb-cb95-36cf-c21d-48f8a7450ad5@FreeBSD.org> <CAG6CVpV7=Dx6VywV0MRY7z7LMwQrBcb-1qUhjngxjFsSZZHvHg@mail.gmail.com> <9c3fc378-ee5e-19ba-c286-1440d4b13615@FreeBSD.org> <20170103102622.GO1923@kib.kiev.ua> <1483458723.16152.107.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jan 03, 2017 at 08:52:03AM -0700, Ian Lepore wrote: > On Tue, 2017-01-03 at 12:26 +0200, Konstantin Belousov wrote: > > On Mon, Jan 02, 2017 at 07:41:26PM -0500, Pedro Giffuni wrote: > > > > > > > > > > > > On 01/02/17 17:54, Conrad Meyer wrote: > > > > > > > > I was suggesting using UINT32_MAX/2 on all platforms (which is > > > > safe > > > > everywhere). > > > > > > > Ah OK. INT_MAX is ~ (UINT_MAX / 2) so it's the same to use either. > > > I just think it's clearer to use INT_MAX and the corresponding int > > > type. > > > > > > The other issue is if diff(1) can handle such lines(?). > > Of course it cannot, on ILP32 arches. > > > > I kind of don't understand the premise of the naysayers in this thread. > šSome machines cannot do lines that are UINT_MAX long, so in that case > we should not support any lines longer than USHORT_MAX? šAs if there > aren't *billions* of line length limits to choose from between those > two numbers? > > I'm also trying to picture the real-world need to diff and patch lines > of ascii text longer than 64K, but for every problem out there, there > is someone with a perverse need to solve that problem outside of the > normal lines we all live between. The original disallow of lines longer than USHORT_MAX can be reasonably interpreted as an attempt to only process patches which have sensible data. The test for UINT_MAX or INT_MAX have no sense at all: what should that check prevent ? On 32bit arches, malloc(3) is guaranteed to fail for such large requests (for typical memory maps, malloc(3) would be unable to allocate even 1G), for 64bit arches this is still an artificial limitation. Might be this is an attempt to provide DoS mitigation ? It is probably too naive for that. In other words, I do see some reasoning in UINT_SHORT limit, is it useful goal or not, is another question. While the check for INT_MAX does not provide any value, IMO.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170103160401.GT1923>