Makefile | 8 5 + 3 - 0 !
1 file changed, 5 insertions(+), 3 deletions(-)

 remove bsdism from makefile
Bug: https://bugs.debian.org/718104

bspatch.c | 4 4 + 0 - 0 !
1 file changed, 4 insertions(+)

 cve-2014-9862 - check for a negative value on numbers of bytes
  The implementation of bspatch does not check for a negative value on numbers

bsdiff.c | 23 14 + 9 - 0 !
1 file changed, 14 insertions(+), 9 deletions(-)

 [patch 1/3] mmap() src file instead of malloc() + read() it
Bug: https://bugs.debian.org/632585

Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>

bsdiff.c | 18 11 + 7 - 0 !
1 file changed, 11 insertions(+), 7 deletions(-)

 [patch 2/3] mmap() dst file instead of malloc() + read() it
Bug: https://bugs.debian.org/632585

This drops the memory pressure since the OS may now drop and reload parts of
the old and new file on demand.

Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>

bsdiff.c | 62 40 + 22 - 0 !
1 file changed, 40 insertions(+), 22 deletions(-)

 [patch 3/3] use int32_t instead off_t for file size
Bug: https://bugs.debian.org/632585

Using off_t (64bit) is kinda waste. With last change we only need 16x the
size of the old file. So for a 2GiB - 1 file we would allocate almost
32GiB (the content of the old file would be loaded on demand from disk).
This is a lot. Since the file size is less than 2GiB we leave the upper 4
bytes unused.
With this change the max file size is limitted to 2GiB - 1 and we require
8x the size of the oldfile which makes almost 16GiB.

When we assume a virtual addess space of 3GiB on a 32bit then the max
oldsize increased from about ~180MiB to ~341MiB.

_If_ some sees this as a regression because files >2GiB can not be used
anymore please provide another binary with -DUSE_OFF_T. The binary has
less than 20KiB.

Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>