[test failure] Re: t4114 binary file becomes symlink

From: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
Date: Jul 18, 2009, 22:51 UTC
Message-ID: <20090718225135.GJ16708@vidovic>
In-Reply-To: <20090718222947.GA31147@coredump.intra.peff.net>

The 18/07/09, Jeff King wrote:

Show 18 quoted lines

> 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