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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jul 20, 2009, 21:56 UTC
Message-ID: <alpine.LFD.2.01.0907201451150.19335@localhost.localdomain>
In-Reply-To: <200907202251.22490.j6t@kdbg.org>

On Mon, 20 Jul 2009, Johannes Sixt wrote:

Show 10 quoted lines

> 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