Thread: #define snprintf _snprintf

The preceding #ifdef MSYS_WIN32 suggests that the macro is specific to one compiler (at a guess, the MINGW compiler suite, as that uses a suite of tools called MSYS), and possibly to one version of that compiler.

When you are migrating to another compiler, you will need to work out what works. One unfortunate consequence of using compiler dependent hacks is that they need to be updated and confirmed to be working correctly every time you migrate to a new compiler.

MSYS_WIN32 will not usually be defined when compiling with VS, so the substitution will not occur. If your VS is recent enough, it supports constructs from the 1999 C standard, so will not have a problem with your code.

Your problem is that snprintf() was not part of the 1989/1990 C standard, and was not part of the C++ standard. It became standard in the 1999 C standard.

Given you are working in C++, support of snprintf() will vary between compilers and compiler versions (some won't support it, some will support something similar like _snprintf(), some will support it).

Given your circumstance, I'd probably attempt to eliminate all calls of snprintf() from the program you are trying to migrate. That may be painful now, but would make any future migrations easier.

Pre-defined C/C++ Compiler Macros
Look up which symbol(s) are predeclared by your compiler. For example _MSC_VER is used by all (except possibly some ancient versions).

Your code should look like

Code:

#ifdef MSYS_WIN32
#define snprintf _snprintf
#elif defined(_MSC_VER)
// do something
#else
#error Need something specific for your compiler here
#endif

If you subsequently went to Borland say, you would get the #error the first time you tried to compile.

Originally Posted by Yarin

If you project is actually C++, you should really be using something else instead, like stringstream. But if it's actually C, then you should compile your sources as such.

I wouldn't go near iostreams with a 10 foot pole on an embedded system. For one thing, it presumes they even exist

Originally Posted by CommonTater

Alternatively he could add a compile time define for MSYS_WIN32 ....
The method of doing that would vary compiler to compiler but it would get around the problem.

Not for a compiler/library that does not support snprintf, or a function that can be directly substituted for it.