All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Sebastian Schuberth <sschuberth@gmail.com>
Cc: Sven Strickroth <sven@cs-ware.de>, Git List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>,
	blees@dcon.de
Subject: Re: [PATCH 1/2] MSVC: vsnprintf in Visual Studio 2015 doesn't need SNPRINTF_SIZE_CORR any more
Date: Wed, 30 Mar 2016 09:49:42 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1603300946410.4690@virtualbox> (raw)
In-Reply-To: <CAHGBnuNkuiyk1uvJqT1_1UWOhpVTg+TxJ2QvepuMBpvOD8AyFw@mail.gmail.com>

Hi Sven & Sebastian,

On Tue, 29 Mar 2016, Sebastian Schuberth wrote:

> On Tue, Mar 29, 2016 at 9:13 PM, Sven Strickroth <sven@cs-ware.de> wrote:

ACK on the patch.

> > diff --git a/compat/snprintf.c b/compat/snprintf.c
> > index 42ea1ac..0b11688 100644
> > --- a/compat/snprintf.c
> > +++ b/compat/snprintf.c
> > @@ -9,7 +9,7 @@
> >   * always have room for a trailing NUL byte.
> >   */
> >  #ifndef SNPRINTF_SIZE_CORR
> > -#if defined(WIN32) && (!defined(__GNUC__) || __GNUC__ < 4)
> > +#if defined(WIN32) && (!defined(__GNUC__) || __GNUC__ < 4) && (!defined(_MSC_VER) || _MSC_VER < 1900)
> >  #define SNPRINTF_SIZE_CORR 1
> >  #else
> >  #define SNPRINTF_SIZE_CORR 0
> 
> I wonder if the logic is (and was) sensible here. We assume that every
> non-__GNUC__ and non-_MSC_VER compiler on Windows requires the
> correction. Wouldn't it make sense to not assume requiring the
> correction unless we know the compiler has this bug? That is,
> shouldn't this better say
> 
> #if defined(WIN32) && (defined(__GNUC__) && __GNUC__ < 4) ||
> (defined(_MSC_VER) && _MSC_VER < 1900))
> #define SNPRINTF_SIZE_CORR 1
> #else
> #define SNPRINTF_SIZE_CORR 0

Since the standard on Windows always was MS Visual C, it should be assumed
that compilers *other* than GCC followed Visual C's lead.

Of course, evidence speaks louder than assumptions.

Therefore I would prefer to keep the current version, at least until we
encounter a case where it is incorrect.

Thanks,
Johannes

  reply	other threads:[~2016-03-30  7:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-29 16:25 [PATCH 1/2] MSVC: vsnprintf in Visual Studio 2015 doesn't need SNPRINTF_SIZE_CORR any more Sven Strickroth
2016-03-29 16:43 ` Junio C Hamano
2016-03-29 19:09 ` Sebastian Schuberth
2016-03-29 19:13   ` Sven Strickroth
2016-03-29 19:20     ` Sebastian Schuberth
2016-03-30  7:49       ` Johannes Schindelin [this message]
2016-03-30  7:57         ` Sebastian Schuberth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.20.1603300946410.4690@virtualbox \
    --to=johannes.schindelin@gmx.de \
    --cc=blees@dcon.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=sschuberth@gmail.com \
    --cc=sven@cs-ware.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.