Re: Breakage in master?

From: Erik Faye-Lund <kusmabite@gmail.com>
Date: Feb 3, 2012, 14:05 UTC
Message-ID: <CABPQNSbQTF1UiDuOZkX-KrTQ7oFyVvx6FxZ85c9uCF2FFUtTSg@mail.gmail.com>
In-Reply-To: <4F2BE759.4000902@gmail.com>

On Fri, Feb 3, 2012 at 2:55 PM, Joel C. Salomon <joelcsalomon@gmail.com> wrote:

Show 17 quoted lines

> On 02/03/2012 07:28 AM, Erik Faye-Lund wrote:
>> On Thu, Feb 2, 2012 at 6:46 PM, Jeff King <peff@peff.net> 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.