[test failure] Re: t4114 binary file becomes symlink

[Nicolas Sebrecht <nicolas.s.dev@gmx.fr>]

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