From owner-svn-src-head@freebsd.org Tue Jan 3 16:04:12 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 396EDC9D87B; Tue, 3 Jan 2017 16:04:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D4CAD1862; Tue, 3 Jan 2017 16:04:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id v03G42KB083483 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 3 Jan 2017 18:04:02 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua v03G42KB083483 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id v03G42lm083482; Tue, 3 Jan 2017 18:04:02 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 3 Jan 2017 18:04:02 +0200 From: Konstantin Belousov To: Ian Lepore Cc: Pedro Giffuni , Conrad Meyer , src-committers , 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> References: <201701021823.v02INWXc028047@repo.freebsd.org> <9c3fc378-ee5e-19ba-c286-1440d4b13615@FreeBSD.org> <20170103102622.GO1923@kib.kiev.ua> <1483458723.16152.107.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1483458723.16152.107.camel@freebsd.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 16:04:12 -0000 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.