id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
7373,Boost ASIO has a wrong swprintf interface definition for MinGW,Lukas Dürrenberger <eXpl0it3r@…>,chris_kohlhoff,"In the file [http://svn.boost.org/svn/boost/trunk/boost/asio/detail/impl/win_static_mutex.ipp win_static_mutex.ipp] on the lines 45-51 one can read:

{{{
#!c++
#if BOOST_WORKAROUND(BOOST_MSVC, >= 1400) && !defined(UNDER_CE)
  swprintf_s(mutex_name, 128,
#else // BOOST_WORKAROUND(BOOST_MSVC, >= 1400) && !defined(UNDER_CE)
  swprintf(mutex_name,
#endif // BOOST_WORKAROUND(BOOST_MSVC, >= 1400) && !defined(UNDER_CE)
      L""asio-58CCDC44-6264-4842-90C2-F3C545CB8AA7-%u-%p"",
      static_cast<unsigned int>(::GetCurrentProcessId()), this);
}}}

As one can see there are two different signatures. The first one is for Visual Studio's swprintf_s function and the second one should be for the rest, but this function is declared differently in MinGW and also takes an integer as second argument.
The correct interface is declared in MinGW's libintl.h header on line 419 as following:
{{{
#!c++
extern int swprintf (wchar_t *, size_t, const wchar_t *, ...);
}}}

That deceleration is also what the C99 standard declares: 
[http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf §7.24.2.3 (p. 362)]

A fix would either involve to change the #else statement completely to add a second parameter as with swprintf_s or another check for MinGW.
Probably the better solution would be to completely eliminate the swprintf function and make use of streams.

If tested the version 1.49, 1.50 and 1.51 and for all, my application fails to build, simply by including the ASIO header.",Bugs,closed,To Be Determined,asio,Boost Development Trunk,Problem,fixed,,