Yeah, xdiff needs a migration from using "long", "int"s to "size_t" etc.
The git community has chosen to disallow diff >1GB files because of the
overflow concern [1].

[1]: https://github.com/git/git/commit/dcd1742e56ebb944c4ff62346da4548e1e3be675


Excerpts from Matt Harbison's message of 2018-03-04 17:00:11 -0500:
> On Sun, 04 Mar 2018 16:45:28 -0500, Matt Harbison <mharbiso...@gmail.com>  
> wrote:
> 
> > # HG changeset patch
> > # User Matt Harbison <matt_harbi...@yahoo.com>
> > # Date 1520197662 18000
> > #      Sun Mar 04 16:07:42 2018 -0500
> > # Node ID c4a6b599a46f93070f5492c9e68566e6be570d2f
> > # Parent  1f9bbd1d6b8ae4f7ea5d9f4310269a3b0242e7b0
> > xdiff: fix trivial build warnings on Windows
> >
> > These are mostly size_t to int/long conversions that are obviously safe,  
> > along
> > with a signed/unsigned comparison.  I don't have clang, so I tried  
> > following the
> > existing whitespace convention in each module.
> 
> The remaining xdiff warnings are:
> 
> mercurial/thirdparty/xdiff/xmerge.c(352) : warning C4244: '=' : conversion  
>  from '__int64' to 'long', possible loss of data
> mercurial/thirdparty/xdiff/xmerge.c(355) : warning C4244: '=' : conversion  
>  from '__int64' to 'long', possible loss of data
> mercurial/thirdparty/xdiff/xutils.c(412) : warning C4244: '=' : conversion  
>  from '__int64' to 'long', possible loss of data
> mercurial/thirdparty/xdiff/xutils.c(415) : warning C4244: '=' : conversion  
>  from '__int64' to 'long', possible loss of data
> 
> These are a bit more concerning, because it looks like two randomish  
> pointers are subtracted.  I haven't spent much time trying to understand  
> the code, so presumably there's something ensuring that these values stay  
> close to each other?  'long' is only 32 bit on Windows, so maybe the size  
> field in mmbuffer_t and mmfile_t should be size_t/ptrdiff_t?
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Reply via email to