path: root/base85.c
AgeCommit message (Collapse)Author
2010-08-12Standardize do { ... } while (0) styleJonathan Nieder
Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2010-01-10Merge branch 'maint-1.6.2' into maintJunio C Hamano
* maint-1.6.2: base85: Make the code more obvious instead of explaining the non-obvious base85: encode_85() does not use the decode table base85 debug code: Fix length byte calculation checkout -m: do not try to fall back to --merge from an unborn branch Conflicts: diff.c
2010-01-10base85: Make the code more obvious instead of explaining the non-obviousAndreas Gruenbacher
Here is another cleanup ... Signed-off-by: Andreas Gruenbacher <> Signed-off-by: Junio C Hamano <>
2010-01-10base85: encode_85() does not use the decode tableAndreas Gruenbacher
Signed-off-by: Andreas Gruenbacher <> Signed-off-by: Junio C Hamano <>
2010-01-10base85 debug code: Fix length byte calculationAndreas Gruenbacher
Signed-off-by: Andreas Gruenbacher <> Signed-off-by: Junio C Hamano <>
2009-06-18Fix big left-shifts of unsigned charLinus Torvalds
Shifting 'unsigned char' or 'unsigned short' left can result in sign extension errors, since the C integer promotion rules means that the unsigned char/short will get implicitly promoted to a signed 'int' due to the shift (or due to other operations). This normally doesn't matter, but if you shift things up sufficiently, it will now set the sign bit in 'int', and a subsequent cast to a bigger type (eg 'long' or 'unsigned long') will now sign-extend the value despite the original expression being unsigned. One example of this would be something like unsigned long size; unsigned char c; size += c << 24; where despite all the variables being unsigned, 'c << 24' ends up being a signed entity, and will get sign-extended when then doing the addition in an 'unsigned long' type. Since git uses 'unsigned char' pointers extensively, we actually have this bug in a couple of places. I may have missed some, but this is the result of looking at git grep '[^0-9 ][ ]*<<[ ][a-z]' -- '*.c' '*.h' git grep '<<[ ]*24' which catches at least the common byte cases (shifting variables by a variable amount, and shifting by 24 bits). I also grepped for just 'unsigned char' variables in general, and converted the ones that most obviously ended up getting implicitly cast immediately anyway (eg hash_name(), encode_85()). In addition to just avoiding 'unsigned char', this patch also tries to use a common idiom for the delta header size thing. We had three different variations on it: "& 0x7fUL" in one place (getting the sign extension right), and "& ~0x80" and "& 0x7f" in two other places (not getting it right). Apart from making them all just avoid using "unsigned char" at all, I also unified them to then use a simple "& 0x7f". I considered making a sparse extension which warns about doing implicit casts from unsigned types to signed types, but it gets rather complex very quickly, so this is just a hack. Signed-off-by: Linus Torvalds <> Signed-off-by: Junio C Hamano <>
2007-05-30decode_85(): fix missing return.Jerald Fitzjerald
When the function detected an invalid base85 sequence, it issued an error message but forgot to return error status at that point and kept going. Signed-off-by: Jerald Fitzjerald <> Signed-off-by: Junio C Hamano <>
2007-04-11(encode_85, decode_85): Mark source buffer pointer as "const".Jim Meyering
Signed-off-by: Jim Meyering <> Signed-off-by: Junio C Hamano <>
2006-05-08improve base85 generated assembly codeNicolas Pitre
This code is arguably pretty hot, if you use binary patches of course. This patch helps gcc generate both smaller and faster code especially in the error free path. Signed-off-by: Nicolas Pitre <> Signed-off-by: Junio C Hamano <>
2006-05-05binary diff: further updates.Junio C Hamano
This updates the user interface and generated diff data format. * "diff --binary" is used to signal that we want an e-mailable binary patch. It implies --full-index and -p. * "apply --allow-binary-replacement" acquired a short synonym "apply --binary". * After the "GIT binary patch\n" header line there is a token to record which binary patch mechanism was used, so that we can extend it later. Currently there are two mechanisms defined: "literal" and "delta". The former records the deflated postimage and the latter records the deflated delta from the preimage to postimage. For purely implementation convenience, I added the deflated length after these "literal/delta" tokens (otherwise the decoding side needs to guess and reallocate the buffer while inflating). Improvement patches are very welcomed. Signed-off-by: Junio C Hamano <>