Date: Tue, 3 Jan 2017 11:27:28 -0500 From: Pedro Giffuni <pfg@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com>, Ian Lepore <ian@freebsd.org> Cc: 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: <f74e0da4-8ff8-95f5-96f1-a3b0c38413d8@FreeBSD.org> In-Reply-To: <20170103160401.GT1923@kib.kiev.ua> 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> <20170103160401.GT1923@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01/03/17 11:04, Konstantin Belousov wrote: > 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. > I think this is a valid reason to leave things as they are. FWIW, both NetBSD and OpenBSD seem be fine with just SHORT_MAX. Given the default width in GNU diff is 130, exceeding USHORT_MAX means the tool is not being used for code. As you say, another question is if we should be limiting the use of patch(1) for code only. > 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. > The check is basically a post-mortem attempt, it is of little relevance and the other BSDs don't have it. Pedro.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f74e0da4-8ff8-95f5-96f1-a3b0c38413d8>