On Fri, Feb 3, 2012 at 2:55 PM, Joel C. Salomon <joelcsalomon@xxxxxxxxx> wrote: > On 02/03/2012 07:28 AM, Erik Faye-Lund wrote: >> On Thu, Feb 2, 2012 at 6:46 PM, Jeff King <peff@xxxxxxxx> wrote: >>> vsnprintf should generally never be returning -1 (it should return the >>> number of characters that would have been written). Since you're on >>> Windows, I assume you're using the replacement version in >>> compat/snprintf.c. >> >> No. SNPRINTF_RETURNS_BOGUS is only set for the MSVC target, not for >> the MinGW target. I'm assuming that means MinGW-runtime has a sane >> vsnprintf implementation. > > That doesn't sound right; MinGW defaults to linking to a fairly old > version of the Windows C library (MSVCRT.dll from Visual Studio 6, > IIRC). According to <http://mingw.org/wiki/C99> there exists libmingwex > with some functions (especially those from <stdio.h>) replaced for > Standard compatibility, but it's "far from complete". (Is msysGit using > it anyway?) I'm not entirely sure what you are arguing. On MinGW, calling vsnprintf vs _vsnprintf leads to different implementations on MinGW. This is documented in the release-notes: http://sourceforge.net/project/shownotes.php?release_id=24832 "As in previous releases, the MinGW implementations of snprintf() and vsnprintf() are the default for these two functions, with the MSVCRT alternatives being called as _snprintf() and _vsnprintf()." I don't see how this is contradicted by your argument of a third, C99-ish implementation. I'm pretty sure the "far from complete"-part is about the C99-features anyway. -- 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