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

[Linus Torvalds <torvalds@linux-foundation.org>]

On Mon, 20 Jul 2009, Johannes Sixt wrote:

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

Not only that, but it's literally how people used to historically do 
things.

Sure, some places do require 'va_copy()', and there's a reason why it got 
added in C99. But there's also a reason why it wasn't added earlier - 
because it didn't exist!

So I agree with Johannes: we should _not_ make our compat version of 
'snprintf()' use va_copy, for the simple reason that

 - modern C library versions will have a working snprintf already

 - old setups that don't have a working snprintf quite likely don't have a 
   va_copy either.

So the set of systems that need both the va_copy _and_ our compat version 
of snprintf is likely much smaller than the set of systems that would 
actively break compilation if they don't have va_copy.

Of course, we could also add a new "NEEDS_VA_COPY" thing, and do

	#ifdef NEEDS_VA_COPY
	  #define va_copy(dst,src) (dst) = (src)
	#endif

or something like that.

		Linus