if use -std=c++0x, will error: d:\ycdeng\qpdev\bin\..\lib\gcc\mingw32\4.4.1\include\c++\cwchar|159|error: '::swprintf' has not been declared| d:\ycdeng\qpdev\bin\..\lib\gcc\mingw32\4.4.1\include\c++\cwchar|166|error: '::vswprintf' has not been declared| ||=== Build finished: 2 errors, 0 warnings ===| if want fix, need #undef __STRICT_ANSI__, see: stdio.h or option is: -U__STRICT_ANSI__ but when change to: -std=gnu++0x, it's OK!
This sounds like a bug in mingw's stdio.h and not GCC.
(In reply to comment #2) > This sounds like a bug in mingw's stdio.h and not GCC. But why -std=gnu++0x is OK? Only -std=c++0x error? So, I think: this is not MinGW's bug, it's GCC.
Because __STRICT_ANSI__ means strict to the standard so -std=c++0x enables __STRICT_ANSI__. But the mingw headers don't know about C++0x standard so it does not know those functions should be enabled.
(In reply to comment #4) > Because __STRICT_ANSI__ means strict to the standard so -std=c++0x enables > __STRICT_ANSI__. But the mingw headers don't know about C++0x standard so it > does not know those functions should be enabled. > Oh. I see. Thanks! I report this bug to MinGW project term now.
(In reply to comment #4) > Because __STRICT_ANSI__ means strict to the standard so -std=c++0x enables > __STRICT_ANSI__. But the mingw headers don't know about C++0x standard so it > does not know those functions should be enabled. > mingw does not yet provide ANSI (c99) compliant swprintf or vswprintf implementations. The functions it does provide, _swprintf and _vswprintf, are pre-c99 MSVCRT implementations. Danny
We had a similar issue elsewhere (see [GLIBCXX_CHECK_C99_TR1]). Essentially, the issue has nothing to do with C++0x, instead with GNU mode vs strict ansi mode, and as such is actually *very* old: appears also for -std=c++98 vs -std=gnu++98, but often it's not noticed because people don't use -std=c++98 very often, as far as I know. The point is simply that the configure check for those functions, in [GLIBCXX_ENABLE_WCHAR_T] is carried out with the default C++ compiler, thus including the GNU extensions, that is the -std=gnu++98 behavior. In linux, both modes enable the same wchar_t functions, but that doesn't happen for mingw, apparently. Is this expected? If you want me to change the configure test to use -std=c++98 just let me know.
Just wanted to add, that eventually, the new C++ standard will be known to the libc implementations, thus the fact that in it the C99 functions are part of the strict ansi mode of operation. This isn't really something we can or should discuss here.
Dave, what do you recommend about this issue? Does it affect cygwin too?
In short, I see two conceptually separate issues: 1- We run the configure tests for those functions in GNU mode, thus if on a target an header doesn't declare some functions in ISO strict mode, the user experiences puzzling errors, like in Comment #1; 2- Specific to MingW (and Cygwin too?!?), those C99 names do not correspond to functions implementing the actual C99 semantics, arguably should indeed not be exposed in strict ISO mode. Thus, my doubt is: should we actually run those configure tests in strict ISO mode, instead of GNU mode? For Linux would not make a difference, and would avoid puzzling errors like those experienced by MingW users. However, I'm afraid some users, on other systems, could be disappointed in finding fewer functions declared in the C++ headers (in namespace std) in GNU mode (which is the default!)
(In reply to comment #9) > Dave, what do you recommend about this issue? Does it affect cygwin too? > This particular problem doesn't occur on cygwin, but we've had similar issues in the past with pre-c99 headers on cygwin (arising from newlib), although it was easier there, since we did actually have the functionality available, so just had to change the headers to make sure it was declared in __STRICT_ANSI__ mode. I don't know how the MinGW guys would best like to go about tackling this, but I'd certainly not suggest changing the configury for /all/ hosts. Adding a host-specific CFLAGs entry during the configure tests would be one way of handling it at the compiler end. Adding the required support in the mingw library will be the ultimate way of handling it. A third option would be for mingw to alias their current _(v)swprintf implementations to the required names as a stop-gap measure, on the grounds that since the resulting compiler/toolchain is going to be not fully conformant anyway until the functions are added, a slightly sub-spec implementation is preferable to an entirely missing one. Danny, it's your call.
Hmm, this issue doesn't occure with mingw-w64 for 32-bit or 64-bit. This is related to the fact that mingw-w64 provides also the wide-character printf/scanf family in unix-way. So I would suggest to close this bug here, as it is a mingw.org runtime issue.
Closed per comment #12