Skip to content
This repository

Aug 12, 2010

  1. jrn

    Standardize do { ... } while (0) style

    Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    authored August 12, 2010 gitster committed August 12, 2010

Jan 10, 2010

  1. Junio C Hamano

    Merge branch 'maint-1.6.2' into maint

    * 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
    authored January 10, 2010
  2. base85: Make the code more obvious instead of explaining the non-obvious

    Here is another cleanup ...
    
    Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    authored January 08, 2010 gitster committed January 09, 2010
  3. base85: encode_85() does not use the decode table

    Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    authored January 08, 2010 gitster committed January 09, 2010
  4. base85 debug code: Fix length byte calculation

    Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    authored January 08, 2010 gitster committed January 09, 2010

Jun 18, 2009

  1. Linus Torvalds

    Fix big left-shifts of unsigned char

    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 <torvalds@linux-foundation.org>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>
    authored June 17, 2009 gitster committed June 18, 2009

May 30, 2007

  1. decode_85(): fix missing return.

    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 <jfj@freemail.gr>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored May 30, 2007 Junio C Hamano committed May 30, 2007

Apr 11, 2007

  1. meyering

    (encode_85, decode_85): Mark source buffer pointer as "const".

    Signed-off-by: Jim Meyering <jim@meyering.net>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored April 10, 2007 Junio C Hamano committed April 11, 2007

May 08, 2006

  1. improve base85 generated assembly code

    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 <nico@cam.org>
    Signed-off-by: Junio C Hamano <junkio@cox.net>
    authored May 08, 2006 Junio C Hamano committed May 08, 2006

May 05, 2006

  1. binary diff: further updates.

    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 <junkio@cox.net>
    authored May 05, 2006
Something went wrong with that request. Please try again.