[test failure] Re: t4114 binary file becomes symlink
From: Nicolas Sebrecht <hidden>
Date: 2016-06-15 22:47:04
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