On 11/5/2012 21:31, Ruben Van Boxem wrote: > 2012/11/5 JonY <jo...@users.sourceforge.net> > >> On 11/5/2012 21:16, Ruben Van Boxem wrote: >>> 2012/11/5 JonY <jo...@users.sourceforge.net> >>> >>>> On 11/5/2012 20:44, Ozkan Sezer wrote: >>>>> >>>>> If older gcc (I guess 4.6 is common as the old gcc) is OK with it, then >>>>> please go ahead. >>>> >>>> When you put it that way, it suddenly hit me that the vfwsprintf will >>>> not really work if the user set -std=c++11 without including any C++ >>>> headers first. Such as when the use include <stdio.h> directly. >>>> >>>> Any suggestions? The guard macro is: >>>> >>>> #if defined(__cplusplus) && (__cplusplus >= 201103L) && >>>> !defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF) >>>> >>>> _GLIBCXX_HAVE_BROKEN_VSWPRINTF will be set (or not) only after including >>>> some basic C++ headers. >>>> >>>> Basically, I didn't want users to be caught surprised. Any changes would >>>> be on the mingw-w64 side, since the gcc change was just removing >>>> _GLIBCXX_HAVE_BROKEN_VSWPRINTF to allow to_string to be used. >>>> >>> >>> The way it would work now, the declaration of a C function would depend >> on >>> the C++ standard in effect. This is mildly worrying and very unexpected. >>> >>> How much trouble would it be to only have the std::vswprintf work in a >> C99 >>> way, and leave ::vswprintf as the broken C function. This would require >>> accommodation by libstdc++ (not sure how receptive they are for these >> kinds >>> of changes), and would at least provide a consistent declaration of the C >>> function. >> >> They aren't really accepting of OS specific hacks. >> > > IMHO, that's just stupid. A C++ library is a layer atop an OS. There's > bound to be incompatibilities. If they're not willing to have OS specific > things in their code, why check for every damn function you use and work > around missing ones? > /rant
Actually, according to http://msdn.microsoft.com/en-us/library/28d5ce15%28v=vs.80%29.aspx In Visual C++ 2005, vswprintf conforms to the ISO C Standard, which requires the second parameter, count, of type size_t. To force the old nonstandard behavior, define _CRT_NON_CONFORMING_SWPRINTFS. The old behavior may not be in a future version, so code should be changed to use the new conformant behavior. We do that to mingw-w64 too? MSVC has this behavior since 2005. Obviously it will break if user defines _CRT_NON_CONFORMING_SWPRINTFS and C++11 at the same time, but that would be PEBCAK.
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ LogMeIn Central: Instant, anywhere, Remote PC access and management. Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d
_______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
