The 18/07/09, Jeff King wrote: > On Sat, Jul 18, 2009 at 09:06:06PM +0200, Johannes Sixt wrote: > > Ah, that's what I was missing. I can reproduce it by setting > SNPRINTF_RETURNS_BOGUS. I think the problem is in the git_vsnprintf > code, and it just by coincidence triggers in this test because of the > exact string we are trying to format. > > Look at compat/snprintf.c. In git_vsnprintf, we are passed a "va_list > ap", which we then repeatedly call vsnprintf on, checking the return to > make sure we have enough space. But using a va_list repeatedly without a > va_end and va_start in the middle invokes undefined behavior. So we need > to va_copy it and use the copy. > > A patch is below, which fixes the problem for me. However, va_copy is > C99, so we would generally try to avoid it. But I don't think there is a > portable way of writing this function without it. And most systems > shouldn't need to use our snprintf at all, so maybe it is portable > enough. I dunno. My investigations made me realize I was building a 64-bits git version in a 32-bits userland (gentoo flag multilib set) which is not the best thing to do. So, another possible fix is to export CFLAGS with '-m32'. Mixing 32 and 64-bits applications is bad. :-) I confirm this patch does fix the failure for the 64 bits version. Thank you all. Now, I wonder if it is safe to run a 32-bits git version on repositories built with a 64-bits version. It should be safe but do you think it actually is? -- Nicolas Sebrecht -- 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