user/sven/git.git/mailmap.c, branch v1.8.0.2

mailmap: avoid out-of-bounds memory access

2012-10-28T11:50:18Z

AddressSanitizer (http://clang.llvm.org/docs/AddressSanitizer.html) complains of a one-byte buffer underflow in parse_name_and_email() while running the test suite. And indeed, if one of the lines in the mailmap begins with '<', we dereference the address just before the beginning of the buffer when looking for whitespace to remove, before checking that we aren't going too far. So reverse the order of the tests to make sure that we don't read outside the buffer. Signed-off-by: Romain Francoise Signed-off-by: Jeff King

mailmap: always return a plain mail address from map_user()

2012-02-06T22:00:06Z

The callers of map_user() give email and name to it, and expect to get the up-to-date email and/or name to be used in their output. The function rewrites the given buffers in place. To optimize the majority of cases, the function returns 0 when it did not do anything, and it returns 1 when the caller should use the updated contents. The 'email' input to the function is terminated by '>' or a NUL (whichever comes first) for historical reasons, but when a rewrite happens, the value is replaced with the mailbox inside the <> pair. However, it failed to meet this expectation when it only rewrote the name part without rewriting the email part, and the email in the input was terminated by '>'. This causes an extra '>' to appear in the output of "blame -e", because the caller does send in '>'-terminated email, and when the function returned 1 to tell it that rewriting happened, it appends '>' that is necessary when the email part was rewritten. The patch looks bigger than it actually is, because this change makes a variable that points at the end of the email part in the input 'p' live much longer than it used to, deserving a more descriptive name. Noticed and diagnosed by Felipe Contreras and Jeff King. Signed-off-by: Junio C Hamano

Merge branch 'ml/mailmap' into maint-1.7.6

2011-12-14T05:12:14Z

* ml/mailmap: mailmap: xcalloc mailmap_info Conflicts: mailmap.c

mailmap: xcalloc mailmap_info

2011-11-17T02:00:56Z

This is to avoid reaching free of uninitialized members. With an invalid .mailmap (and perhaps in other cases), it can reach free(mi->name) with garbage for example. Signed-off-by: Marc-André Lureau Signed-off-by: Junio C Hamano

mailmap: fix use of freed memory

2010-10-14T02:11:26Z

On an x86_64 system (F13-based), I ran these commands in an empty directory: git init printf '%s\n' \ ' ' \ 'John ' > .mailmap git shortlog < /dev/null Here's the result: (reading log message from standard input) *** glibc detected *** git: free(): invalid pointer: 0x0000000000f53730 *** ======= Backtrace: ========= /lib64/libc.so.6[0x31ba875676] git[0x48c2a5] git[0x4b9858] ... zsh: abort (core dumped) git shortlog What happened? Some .mailmap entry is of the form, while a subsequent one looks like "User Name , and the two email addresses on the right are not identical but are "equal" when using a case-insensitive comparator. Then, when add_mapping is processing the latter line, new_email is NULL and we free me->email, yet do not replace it with a new strdup'd string. Thus, when later we attempt to use the buffer behind that ->email pointer, we reference freed memory. The solution is to free ->email and ->name only if we're about to replace them. [jc: squashed in the tests from Jonathan] Signed-off-by: Jim Meyering Signed-off-by: Jonathan Nieder Signed-off-by: Junio C Hamano

string_list: Fix argument order for string_list_lookup

2010-06-27T17:06:51Z

Update the definition and callers of string_list_lookup to use the string_list as the first argument. This helps make the string_list API easier to use by being more consistent. Signed-off-by: Julian Phillips Signed-off-by: Junio C Hamano

string_list: Fix argument order for string_list_insert_at_index

2010-06-27T17:06:51Z

Update the definition and callers of string_list_insert_at_index to use the string_list as the first argument. This helps make the string_list API easier to use by being more consistent. Signed-off-by: Julian Phillips Signed-off-by: Junio C Hamano

string_list: Fix argument order for string_list_insert

2010-06-27T17:06:51Z

Update the definition and callers of string_list_insert to use the string_list as the first argument. This helps make the string_list API easier to use by being more consistent. Signed-off-by: Julian Phillips Signed-off-by: Junio C Hamano

mailmap.c: remove unused function

2010-01-12T09:06:09Z

map_email() is not used anywhere. Signed-off-by: Junio C Hamano

Fix various sparse warnings in the git source code

2009-06-21T04:52:55Z

There are a few remaining ones, but this fixes the trivial ones. It boils down to two main issues that sparse complains about: - warning: Using plain integer as NULL pointer Sparse doesn't like you using '0' instead of 'NULL'. For various good reasons, not the least of which is just the visual confusion. A NULL pointer is not an integer, and that whole "0 works as NULL" is a historical accident and not very pretty. A few of these remain: zlib is a total mess, and Z_NULL is just a 0. I didn't touch those. - warning: symbol 'xyz' was not declared. Should it be static? Sparse wants to see declarations for any functions you export. A lack of a declaration tends to mean that you should either add one, or you should mark the function 'static' to show that it's in file scope. A few of these remain: I only did the ones that should obviously just be made static. That 'wt_status_submodule_summary' one is debatable. It has a few related flags (like 'wt_status_use_color') which _are_ declared, and are used by builtin-commit.c. So maybe we'd like to export it at some point, but it's not declared now, and not used outside of that file, so 'static' it is in this patch. Signed-off-by: Linus Torvalds Signed-off-by: Junio C Hamano