Opened 10 years ago
Closed 10 years ago
#7373 closed Bugs (fixed)
Boost ASIO has a wrong swprintf interface definition for MinGW
Reported by: | Owned by: | chris_kohlhoff | |
---|---|---|---|
Milestone: | To Be Determined | Component: | asio |
Version: | Boost Development Trunk | Severity: | Problem |
Keywords: | Cc: |
Description
In the file win_static_mutex.ipp on the lines 45-51 one can read:
#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:
extern int swprintf (wchar_t *, size_t, const wchar_t *, ...);
That deceleration is also what the C99 standard declares: §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.
Change History (2)
comment:1 by , 10 years ago
Component: | None → asio |
---|---|
Owner: | set to |
comment:2 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
(In [82290]) Merge from trunk: