On Sat, Apr 09, 2016 at 09:02:38AM +0200, Tom G. Christensen wrote: > I've finished testing 2.8.1 and I found one more case where a null is being > printed and causing a segfault. This happens even on Solaris 8 and 9. > The failling test is t3200.63. Oh good, this one wasn't me. :) It's just a normal "oops, we feed NULL and nobody on glibc noticed because it silently replaced it with "(null)" case. I did find a few other oddities while fixing it, though. +cc Patrick, who worked in this area most recently. [1/3]: config: lower-case first word of error strings [2/3]: git_config_set_multivar_in_file: all non-zero returns are errors [3/3]: git_config_set_multivar_in_file: handle "unset" errors I think we may want some additional improvements. While doing 1/3, I noticed that many of these error messages could stand to be marked for translation. As other people are already looking at mass-conversion, I stopped short of doing it here (and merely contented myself with throwing a conflict into their patches ;) ). The other thing is that 2/3 notices the error return from the config-setting functions is weird. It's sometimes negative and sometimes positive. I fixed this caller, but I think it's possible for the negative values to leak into our exit codes: $ touch .git/config $ git config foo.bar baz error: could not lock config file .git/config: File exists $ echo $? 255 I seem to recall some systems having trouble with negative error codes, so we may want to make that more consistent. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html