Modify bsdiff 4.3 to goobsdiff, which is appropriate for use as the Mac binary differ/patcher

Modify bsdiff 4.3 to create goobsdiff, which is appropriate for use as the Mac
binary differ/patcher.

BUG=45017
TEST=none

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=49316

[TVL, 2010-06-09 20:43:01]

http://codereview.chromium.org/2716005/diff/7001/8004
File chrome/installer/mac/third_party/bsdiff/goobsdiff.c (right):

http://codereview.chromium.org/2716005/diff/7001/8004#newcode366
chrome/installer/mac/third_party/bsdiff/goobsdiff.c:366: 91	5	unused
you could sneak in a crc32 the rest of the headers and 3 payloads (so a patch
can be validated, bzip/gzip provide crc for their chunks, but if you use
uncompressed, they would be no check)

http://codereview.chromium.org/2716005/diff/7001/8006
File chrome/installer/mac/third_party/bsdiff/goobspatch.c (right):

http://codereview.chromium.org/2716005/diff/7001/8006#newcode62
chrome/installer/mac/third_party/bsdiff/goobspatch.c:62: for (i = 0; i < 20;
++i)
SHA_DIGEST_LENGTH?

http://codereview.chromium.org/2716005/diff/7001/8006#newcode81
chrome/installer/mac/third_party/bsdiff/goobspatch.c:81: static void
cfopen(cfile *cf, const char *path, off_t off,
you could pass an "expectedLength" here, and store it in the struct as
"bytesLeft" then in the cfread call, check to see if there are atleast that many
bypes left and dec the count after the read.  This way you make sure no
corruption makes you overread from within the file.  add a call like cfeof to
confirm everything was read, and you can make sure there wasn't something extra
when the blocks are done with their work.

http://codereview.chromium.org/2716005/diff/7001/8006#newcode186
chrome/installer/mac/third_party/bsdiff/goobspatch.c:186: char sha1str[41],
expected_sha1str[41];
SHA_DIGEST_LENGTH*2+1?

http://codereview.chromium.org/2716005/diff/7001/8006#newcode225
chrome/installer/mac/third_party/bsdiff/goobspatch.c:225: magic = offtin(header
+ 88);
what is "magic" for?  this the last part of the header which would be encodings
and white space?

[TVL, 2010-06-09 21:04:14]

lg

[Mark Mentovai, 2010-06-09 21:06:50]

thomasvl@chromium.org wrote:
> http://codereview.chromium.org/2716005/diff/7001/8004#newcode366
> chrome/installer/mac/third_party/bsdiff/goobsdiff.c:366: 91     5
> unused
> you could sneak in a crc32 the rest of the headers and 3 payloads (so a
> patch can be validated, bzip/gzip provide crc for their chunks, but if
> you use uncompressed, they would be no check)

This is complex and I don’t believe it’s necessary but I could be
convinced if you feel strongly.

> http://codereview.chromium.org/2716005/diff/7001/8006#newcode81
> chrome/installer/mac/third_party/bsdiff/goobspatch.c:81: static void
> cfopen(cfile *cf, const char *path, off_t off,
> you could pass an "expectedLength" here, and store it in the struct as
> "bytesLeft" then in the cfread call, check to see if there are atleast
> that many bypes left and dec the count after the read.  This way you
> make sure no corruption makes you overread from within the file.  add a
> call like cfeof to confirm everything was read, and you can make sure
> there wasn't something extra when the blocks are done with their work.

This is difficult because the “expected” values are the lengths of the
encoded stream but the cfile interface deals in decoded/decompressed
lengths.

I’ve made the other changes.

Mark