Re: [test failure] Re: t4114 binary file becomes symlink

From: Johannes Sixt <j6t@kdbg.org>
Date: Jul 20, 2009, 20:51 UTC
Message-ID: <200907202251.22490.j6t@kdbg.org>
In-Reply-To: <20090720090937.GA20412@sigill.intra.peff.net>

On Montag, 20. Juli 2009, Jeff King wrote:

Show 17 quoted lines

> On Sun, Jul 19, 2009 at 01:01:15PM +0200, Johannes Sixt wrote:
> > Problem is, snprintf was made for very old systems, which typically do
> > not have va_copy. (E.g. Windows, but there the situation *might* have
> > changed with the switch to gcc 4.)
> >
> > The rationale not to use va_copy is that this function is to be used
> > *only* if necessary, i.e. portability is already lacking, and if it
> > can be verified that this function works as is. Portability and
> > correct-by-the-law C code are *not* a goal here. If the function does
> > not work as is, don't use it.
>
> OK, I guess I can buy the "don't use this unless you need it" rationale.
> But two questions:
>
>   1. _Are_ we sure it works under Windows?  That is, do we know for a
>      fact that using a va_list twice is OK there, or are we just going
>      on the fact that nobody has reported the bug?

We are sure (well, I am sure ;) that it worked on Windows with gcc 3. It certainly is a reasonable workaround. It remains to confirm that the workaround works as expected on the other systems that use it (IRIX, HP/UX). 'git branch -v' is a test that calls the system provided vsnprintf twice (as long as the branch head commits have moderatly long summary lines).

On Windows, however, today everybody who compiles git is most likely using msysgit's gcc 4.4. This version has C99 vsnprintf, and the workaround should not be used anymore, although it does not hurt.

-- Hannes