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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Montag, 20. Juli 2009, Jeff King wrote:
> 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
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]