37

When I compile cocos2d-x (version 3.3) using visual studio 2015, an error occured, saying:

fatal error C1189: #error: Macro definition of snprintf conflicts with Standard Library function declaration (编译源文件 ..\base\s3tc.cpp)

The source code is: 

#ifdef snprintf
    #error Macro definition of snprintf conflicts with Standard Library 
             function declaration
#endif

Anybody can tell me what's wrong?

Magnilex
  • 11,584
  • 9
  • 62
  • 84
Jared
  • 371
  • 1
  • 3
  • 4

3 Answers3

62

Until now, Many libraries & programs used snprintf() function by defining it as _snprintf(), since _snprintf() was supported.

#define snprintf _snprintf

Finally, Visual Studio 14 defines snprintf()!

Since, snprintf() is now officially supported. We should never #define it.

Doing it will overshadow new snprintf() function defined in stdio.h.

To restrict that, this is added in stdio.h

#ifdef snprintf
    #error: Macro definition of snprintf conflicts with Standard Library function declaration”
#endif

Hence, your code doesn't compile.

It is true that on all previous versions of Visual Studio, you must use _snprintf() function. But VS 2014 onwards you should not #define it with _snprintf().

Somewhere in your code or most likely in cocos headers, this is done and hence the error.

Check that and remove that #define.

snprintf() is part of C99 specifications.

To enable C99 support

add this in your program

#if _MSC_VER>=1900
#  define STDC99
#endif

In case you don't know what _MSC_VER macro values are

...
MSVC++ 14.0 _MSC_VER == 1900 (Visual Studio 2015)
MSVC++ 12.0 _MSC_VER == 1800 (Visual Studio 2013)
MSVC++ 11.0 _MSC_VER == 1700 (Visual Studio 2012)
MSVC++ 10.0 _MSC_VER == 1600 (Visual Studio 2010)
MSVC++ 9.0  _MSC_VER == 1500 (Visual Studio 2008)
MSVC++ 8.0  _MSC_VER == 1400 (Visual Studio 2005)
MSVC++ 7.1  _MSC_VER == 1310 (Visual Studio .NET 2003)
MSVC++ 7.0  _MSC_VER == 1300
MSVC++ 6.0  _MSC_VER == 1200
MSVC++ 5.0  _MSC_VER == 1100
MSVC++ 4.0  _MSC_VER == 1000
MSVC++ 2.0  _MSC_VER ==  900
MSVC++ 1.0  _MSC_VER ==  800
C/C++  7.0  _MSC_VER ==  700
C      6.0  _MSC_VER ==  600
martinec
  • 7
  • 5
user1
  • 4,031
  • 8
  • 37
  • 66
  • Please note that `#define snprintf _snprintf` should never be used. It is unsafe as `_snprintf()` doesn't guarantee null-termination unlike C99's `snprintf()`. There are also other differences. – cremno Nov 06 '15 at 23:34
  • @cremno, Is this your comment or answer? I think you have misunderstood the whole point I am making here. – user1 Nov 07 '15 at 00:23
  • It's just a comment. Your answer is fine. – cremno Nov 07 '15 at 00:59
  • What about adding a stub to define the old name to allow old libs (that otherwise should work with any compiler version) to work? – JDługosz Dec 31 '15 at 09:55
  • I have this problem in a public library that needs to keep working with older VS versions. I wrapped the offending #define sprintf with #if _MSC_VER<1900 ... #endif and yes I know this is obvious to many of you. – Spike0xff Mar 07 '16 at 19:55
  • Thanks for the solution.If I compile libs in VS 2013 it is not working in VS 2015. Same goes the other way. Can we make changes in lib source so one lib can work on both versions of VS? – Deep Joshi Jan 04 '18 at 03:02
5

Just find the definition of snprintf in your code and undefine it while on VS2015.
Something like: 

#if _MSC_VER < 1900 //vs2015 already have this function
#define snprintf _snprintf_s 
#endif
Jay Zhang
  • 109
  • 3
  • 11
3

user1 is right

But even if you fix the problem this way, you'll probably face linker problems with prebuilt libraries.

The way to avoid this is to change platform toolset on all projects to Visual Studio 2013 (v120)

And in linker/input propry page add libcmt.lib to Ignore Specific Default libraries: libcmt.lib;libcmtd.lib;...

user1185287
  • 41
  • 1
  • 2
  • 5
    OP and others who look up this issue will likely not have the luxury to stick with VS2013 just to avoid an error. – kayleeFrye_onDeck Jul 23 '15 at 19:37
  • 2
    @kayleeFrye_onDeck , user1185287 is not suggesting using VS2013, but to change the **toolset** used to compile, from the project properties (General Tab) directly from VS2015 – Chris Oct 20 '15 at 21:33
  • I gotcha. The point, in its essence still stands, though. We all eventually have to "trade-up" :) – kayleeFrye_onDeck Oct 21 '15 at 01:13