#1220 Latest MingW download breaks g++ -ansi option

[Mark Cave-Ayland]

Hi everyone,

I've been using a MingW 4 installation for a couple of years, and have recently started again by downloading the Windows installer and grabbing the latest versions of MingW and MSYS at the time of writing. However, I have noticed a regression in that one of the libraries I regularly compile with MingW now fails with the following error:

In file included from
C:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/
c++/3.4.5/bits/postypes.h:46,
from
C:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/
c++/3.4.5/iosfwd:50,
from
C:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/
c++/3.4.5/ios:44,
from
C:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/
c++/3.4.5/ostream:45,
from
C:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/
c++/3.4.5/iostream:45,
from test.cpp:1:
C:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/cwchar:161:
error: `::swprintf' has not been declared
C:/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/c++/3.4.5/cwchar:168:
error: `::vswprintf' has not been declared

With some detective work, I managed to find out that the problem is due to the fact that g++ is invoked in ANSI mode with the -ansi parameter that the compilation fails. The error can easily be reproduced by compiling a simple "Hello World" program called test.cpp like this:

#include <iostream>

using namespace std;

main()
{
cout << "Hello World";
}

with the following command line:

g++ -ansi -o test.exe test.cpp

After a bit of fiddling, I found that I was able to get my test program above to compile in ANSI mode by loading include/c++/3.4.5/cwchar and commenting out the lines containing "using ::swprintf" and "using ::vswprintf".

I think that this related to the fact that the swprintf() and vswprintf() functions in wchar.h are surrounded by an "#ifndef __STRICT_ANSI__" declaration; however I am not sure whether or not surrounding the "using" lines mentioned above with the same declaration is the correct thing to do in C++.

Many thanks,

Mark.

[Anonymous]

hi there!
in file cwchar, i enclosed using ::swprintf and using ::vswprintf statements with #ifndef __STRICT_ANSI__ and #endif
after doing this i was able to compile the above code in ANSI mode

[Anonymous]

the modification i made fixed the problem after i surrounded using ::swprintf and using ::vswprintf by #ifndef __STRICT_ANSI__

[dipesh]

As workaround, cause we cannot demand customers to update there mingw, we added following to our products;

#if (defined(__MINGW32__) || defined(__MINGW64__)) && (__GNUC__ == 4) && (__GNUC_MINOR__ == 4) && (__GNUC_PATCHLEVEL__ == 0)
// workaround a mingw bug, http://sourceforge.net/tracker/index.php?func=detail&aid=2373234&group_id=2435&atid=102435
int swprintf (wchar_t *, size_t, const wchar_t *, ...);
int vswprintf(wchar_t *, const wchar_t *, va_list);
#endif

[Keith Marshall]

dipesh:
Your work around makes little or no sense; this is in no way specific to *any* version of GCC, so your application to only GCC-4.4.0 seems inappropriate.

The root cause is this change in the mingw runtime:
2008-07-04 Danny Smith <...>

*include/stdio.h (swprintf, vswprintf): Guard with #ifndef __STRICT_ANSI__
*include/wchar.h (swprintf, vswprintf): Likewise.

Now, I imagine that Danny made that change because the Microsoft implementations of this pair of functions are distinctly non-ANSI conformant; perhaps, without that guard, he observed some other problem resulting from the non-ANSI conformant declarations, when compiling strictly ANSI conforming source.

Unfortunately, his change has caused this issue, because the cwchar header, (which is *not* a mingw runtime header -- it is furnished by GCC itself), gratuitously assumes that prototypes for this pair of functions have been declared, and Danny has voided that for the __STRICT_ANSI__ case. Since Danny is primarily a GCC maintainer, and since it is his patch to mingw runtime which has introduced this inconsistency, I am referring the issue to him, with escalated priority, for resolution.

[Keith Marshall]

Bug #2797669 is a duplicate of this bug.
https://sourceforge.net/tracker/?func=detail&aid=2797669&group_id=2435&atid=102435

[Danny Smith]

This was fixed in GCC trunk by

2009-07-24 Joseph Myers <joseph at codesourcery dot com>

\* include/c\_global/cwchar \(swprintf, vswprintf\): Do not use if
\_GLIBCXX\_HAVE\_BROKEN\_VSWPRINTF.
\* testsuite/lib/libstdc++.exp \(check\_v3\_target\_swprintf\): New.
\* testsuite/lib/dg-options.exp \(dg-require-swprintf\): New.
\* testsuite/21\_strings/headers/cwchar/functions\_std.cc,
testsuite/27\_io/basic\_ostream/inserters\_arithmetic/wchar\_t/4402.cc,
testsuite/27\_io/basic\_ostream/inserters\_other/wchar\_t/error\_code.cc:
Use dg-require-swprintf.

[Keith Marshall]

Thanks, Danny.

Unfortunately, that change will not have percolated through to any MinGW release of GCC yet, so in the interim we are stuck with a severe inconsistency between GCC and MinGW runtime. Do you recall why you felt it necessary to impose the 2008-07-04 restriction for __STRICT_ANSI__? I'm wondering if it might not be best, in the interim, to revert that change, or at least to make the restriction less draconian; perhaps the guards in include/stdio.h and include/wchar.h could be changed to something like:

#if ! defined __STRICT_ANSI__ \ || (defined __cplusplus && ! defined _GLIBCXX_HAVE_BROKEN_VSWPRINTF )

for a more effective solution?

[Keith Marshall]

Bug #2925669 is a duplicate of this bug.
https://sourceforge.net/tracker/?func=detail&aid=2925669&group_id=2435&atid=102435

[Jacky Lai]

I posted a patch for this:
https://sourceforge.net/tracker/?func=detail&aid=2955991&group_id=2435&atid=302435

[Earnie Boyd]

Keith, isn't this out-of-date? Or perhaps a duplicate?

[Earnie Boyd]

I'm closing as out-of-date but there are other issues related to swprintf and vswprintf still open.

[#1807]

[Georger Araujo]

Hi,
I just ran into this very issue with the latest stable (as of 2013/08/28). The following program compiles fine without -std=c++11, but fails when I add it:

#include <stdio.h>
int main()
{
    FILE * file = _wfopen( L"main.cpp", L"rb" );
    fclose( file );
    return 0;
}

Any progress on this?