Thread (24 messages) flat view 24 messages, 8 authors, 2016-06-15

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

From: Johannes Sixt <hidden>
Date: 2016-06-15 22:47:04

On Montag, 20. Juli 2009, Jeff King wrote:
On Sun, Jul 19, 2009 at 01:01:15PM +0200, Johannes Sixt wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help