svn commit: r311109 - head/usr.bin/patch

[Pedro Giffuni]

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
>