Date: Tue, 3 Jan 2017 11:08:28 -0500 From: Pedro Giffuni <pfg@FreeBSD.org> To: Ian Lepore <ian@freebsd.org>, Konstantin Belousov <kostikbel@gmail.com> 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: <385c8ef6-32b9-c703-14d8-2c10f5816b44@FreeBSD.org> 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
Hi Ian; On 01/03/17 10:52, 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 am considering INT_MAX, which, I think can be reasonably supported by all archs. I looked briefly at GNU diff, and it has a way of specifying the width. It does look like it can handle ints but the default is 130. So yes, it seems supporting something larger than USHORT_MAX may be useful in these "big data" era but it's not urgent. > 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. > Pedro. > -- Ian >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?385c8ef6-32b9-c703-14d8-2c10f5816b44>