Visual Studio: Resolving build Flags/Settings for a project dependency

I'm trying to compile a C/C++ library, originally developed for *nix systems, on windows Visual Studio 2019 and it's hitting a snag in a dependency; boost in this case. The error reported is as follows :

Error C2039 '_snprintf': is not a member of 'std'

I believe the egregious lines are the following :

#if ( defined(_MSC_VER) && _MSC_VER < 1900 ) || ( defined(__MINGW32__) && 
!defined(__MINGW64_VERSION_MAJOR) )

inline char const * unknown_message_win32( int ev, char * buffer, std::size_t len )
{
# if defined( BOOST_MSVC )
#  pragma warning( push )
#  pragma warning( disable: 4996 )
# endif

    _snprintf( buffer, len - 1, "Unknown error (%d)", ev );

    buffer[ len - 1 ] = 0;
    return buffer;

# if defined( BOOST_MSVC )
#  pragma warning( pop )
# endif
}

#else

inline char const * unknown_message_win32( int ev, char * buffer, std::size_t len )
{
    std::snprintf( buffer, len, "Unknown error (%d)", ev );
    return buffer;
}

#endif

Another forum discussed that std::snprintf either did or does now map to std::_snprintf in the standard library and that this was deprecated/implemented a while ago. Indeed if I remove && _MSC_VER < 1900 then this part of the build succeeds; granted it's still broken but its elsewhere. This leads me to the following questions ?

Are _MSC_VER, BOOST_MSVC and __MINGW32__ flags, values or settings and how could one determine this ?
Where can one enable/disable/set/assign/alter/override these values ? That is where are they defined e.g. command line switches, other header/configuration file and how can one know this ?
How can I determine which of these variables/constants are active/effective during compilation in Visual Studio 2019 ?
Should this be done for the project I'm compiling or should I be doing this for the dependency, boost in this case ?
Simply editing the header file as I have described is, in general, bad practice. Is there a better way to patch the file ? Why does C not check that this is altered and throw some other error ?
Should I be finding another version of the library that resolves this or should I be reporting this as a bug to the developers, again for the main package or for boost ?

Note: I get that these might be introductory questions but I do not use C/C++ especially often. I find that all the interesting C/C++ libraries are a pain to build and one looses interest after spending a day or two fighting to get the compiler setup with an appropriate build system not only for the package itself but also for each of its dependencies. More often then not the instructions are cryptic, terse and/or dated and just about every tool wants to clobber ones systems' configuration in some way. This seems like a nice example where one can succinctly isolate the issue, identify its cause and resolve some of my queries for once.

Solution

_MSVC_VER is defined by the compiler itself and will always be present when using MSVC (I believe it will also be present when using the clang distributed through VS but I'm not as certain of that). BOOST_VER will be present after (and in the middle of) boost headers. BOOST_VER is defined early in the boost header cascade. __MINGW64_VER wwill only be defined when using the mingw toolset.

If the problem in question is showing up somewhere in a boost header (which from your description I suspect to be the case) then yes, boost is the appropriate package to inform about the issue. They are much more likely to act on it if you can provide a fix that does not appear to screw with anything else (not always an easy task when it comes to boost libraries). And

Also, if your boost library is not the most current (1.75 right now, soon to be 1.76) I suggest you do update that first and check if the problem has already been resolved.