threads / patch / 41863

patch, 2 partsMSVC: vsnprintf in Visual Studio 2015 doesn't need SNPRINTF_SIZE_CORR any more

Subject: [PATCH 1/2] MSVC: vsnprintf in Visual Studio 2015 doesn't need SNPRINTF_SIZE_CORR any more

## tl;dr

7 messages between Mar 29, 2016 and Mar 30, 2016. Diffs are folded; open one to read it.

replies: 6people: 4as markdown or json

Sven Strickroth· Mar 29, 2016, 16:25 UTC · lore

In MSVC2015 the behavior of vsnprintf was changed. W/o this fix there is one character missing at the end.

Signed-off-by: Sven Strickroth <sven@cs-ware.de>
---
 compat/snprintf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Show changes to compat/snprintf.c +1 −1

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

-- 
2.7.4.windows.1

Junio C Hamano· Mar 29, 2016, 16:43 UTC · re: Sven Strickroth · lore

Re: [PATCH 1/2] MSVC: vsnprintf in Visual Studio 2015 doesn't need SNPRINTF_SIZE_CORR any more

Sven Strickroth <sven@cs-ware.de> writes:

Show 5 quoted lines

> In MSVC2015 the behavior of vsnprintf was changed.
> W/o this fix there is one character missing at the end.
>
> Signed-off-by: Sven Strickroth <sven@cs-ware.de>
> ---

Thanks.

I am not qualified to judge the correctness of the assertion that MSVC at or more recent than version 1900 does not need the correction and will wait for Windows folks to Ack.

Thanks.

Show 16 quoted lines

>  compat/snprintf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> 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

Sebastian Schuberth· Mar 29, 2016, 19:09 UTC · re: Sven Strickroth · lore

Re: [PATCH 1/2] MSVC: vsnprintf in Visual Studio 2015 doesn't need SNPRINTF_SIZE_CORR any more

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

> In MSVC2015 the behavior of vsnprintf was changed.
> W/o this fix there is one character missing at the end.

How about adding a link to [1] in the commit message and quoting the central "Beginning with the UCRT in Visual Studio 2015 and Windows 10, vsnprintf is no longer identical to _vsnprintf. The vsnprintf function complies with the C99 standard; _vnsprintf is retained for backward compatibility" statement?

[1] https://msdn.microsoft.com/en-us/library/1kt27hek.aspx

-- 
Sebastian Schuberth

Sven Strickroth· Mar 29, 2016, 19:13 UTC · re: Sebastian Schuberth · lore

Re: [PATCH 1/2] MSVC: vsnprintf in Visual Studio 2015 doesn't need SNPRINTF_SIZE_CORR any more

"Beginning with the UCRT in Visual Studio 2015 and Windows 10, vsnprintf is no longer identical to _vsnprintf. The vsnprintf function complies with the C99 standard; _vnsprintf is retained for backward compatibility" [1]

W/o this fix there is one character missing at the end.

[1] https://msdn.microsoft.com/en-us/library/1kt27hek.aspx

Signed-off-by: Sven Strickroth <sven@cs-ware.de>
---
 compat/snprintf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Show changes to compat/snprintf.c +1 −1

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

-- 
2.7.4.windows.1

Sebastian Schuberth· Mar 29, 2016, 19:20 UTC · re: Sven Strickroth · lore

Re: [PATCH 1/2] MSVC: vsnprintf in Visual Studio 2015 doesn't need SNPRINTF_SIZE_CORR any more

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

Show 13 quoted lines

> 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

-- 
Sebastian Schuberth

Johannes Schindelin· Mar 30, 2016, 07:49 UTC · re: Sebastian Schuberth · lore

Re: [PATCH 1/2] MSVC: vsnprintf in Visual Studio 2015 doesn't need SNPRINTF_SIZE_CORR any more

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.

Show 25 quoted lines

> > 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

Sebastian Schuberth· Mar 30, 2016, 07:57 UTC · re: Johannes Schindelin · lore

Re: [PATCH 1/2] MSVC: vsnprintf in Visual Studio 2015 doesn't need SNPRINTF_SIZE_CORR any more

On Wed, Mar 30, 2016 at 9:49 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 26 quoted lines

>> >  #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.

Fine with me. It's probably better not to change the logic as we wouldn't know whether this would break things for some exotic compiler currently in use to compile Git.

Also ACK from my side on the path then.

-- 
Sebastian Schuberth