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
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
