Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#292 -Wformat warnings broken in C++

closed-fixed
nobody
crt (84)
5
2012-05-10
2012-05-04
White-Tiger
No

I've been searching and trying to fix it for Hours/Days now to finally find out it's a MinGW64 bug^^
See: http://cygwin.com/ml/cygwin/2012-01/msg00054.html
basically I've got the same problem as the one in the link above since GCC 4.7 using http://sourceforge.net/projects/mingwbuilds/ or other sources (before that I used TDM-GCC 4.6.1 which works fine but is outdated)
__USE_MINGW_ANSI_STDIO is enabled by default even when I didn't want to (eg. didn't define it by myself) and as such printf macros like PRIu64 resolves to "llu" on Windows although it should be "I64u" and I'll get Compiler warnings about unknown conversion type character 'l' in format

I'm fine with using __USE_MINGW_ANSI_STDIO if it's faster then MSVCRT but not when it's not. Also I can't live with wrong compiler warnings as they happen here since they have to help me and not to do the opposite. (disabling them isn't an option since I'm not warned about real problems then as well)

Currently I'm unsure if it's a MinGW bug in general or just a GCC/porting bug...

Discussion

  • Kai Tietz
    Kai Tietz
    2012-05-07

    The issue why __USE_MINGW_ANSI_STDIO is enabled for use of libstdc++ by default is that this library depends on the use of GNUish printf/scanf styles.
    The warning you see is strange, as we define in our headers those functions explicit with proper format-attribute. Another point I simply don't get is your claim that PRIu64 should be "I64u" for __USE_MINGW_ANSI_STDIO defined, which is plain wrong. If GNUish printf/scanf rountines are used, this macro has to be "llu", as "I64u" isn't supported as GNUish formatter. Even worse 'I' has for GNUish formatter a special meaning absolutely incompatible to that on of VC.

    If you are using PRIxxx/SCNxxx macros on none-C-runtime printing routines, then it is a fault of the code, too.

    So I see this report as invalid.

    Regards,
    Kai

    PS: If you want to use MS-printf routines in C++, you need to avoid include of C++-headers. By this the macro __USE_MINGW_ANSI_STDIO remains deactivated. At least as work-a-round this might help you.

     
  • Kai Tietz
    Kai Tietz
    2012-05-07

    • status: open --> pending-invalid
     
  • White-Tiger
    White-Tiger
    2012-05-07

    • status: pending-invalid --> open-works-for-me
     
  • White-Tiger
    White-Tiger
    2012-05-07

    “Another point I simply don't get is
    your claim that PRIu64 should be "I64u" for __USE_MINGW_ANSI_STDIO defined,
    which is plain wrong”
    Sry I didn't meant to say that it should be "I64u" for MINGW_ANSI_STDIO, it's "llu" then^^ nvm

    Anyway.. this "report" (it actually isn't a report since I don't know how to describe it proper...) isn't invalid and now somewhat solved for me ;)
    Christian Franke posted a patch on the MinGW mailing-list to solve the "-Wformat warnings" which can be found on the archive here: https://sourceforge.net/mailarchive/message.php?msg_id=28688914
    Direct Link to attached patch: https://sourceforge.net/mailarchive/attachment.php?list_name=mingw-w64-public&message_id=4F15BAE7.9070606%40t-online.de&counter=1

    This "only" surrounds all MinGW overwrite functions (printf etc.) with
    #ifdef __cplusplus
    extern "C" {
    #endif
    [...]
    #ifdef __cplusplus
    }
    #endif

    and thus fixes to problem for C++ but doesn't change anything for C. It works this way for me and I can live with that.
    I'm also using c++0x in my test program, dunno if that makes any difference. Also note that this "-Wformat warnings" only occur with C++ using "g++". "gcc" seems to work (didn't tested that, but that's what I read IIRC)

    PS: just read the mailing-list entries to get into it, starting at: https://sourceforge.net/mailarchive/message.php?msg_id=28633223

     
  • Kai Tietz
    Kai Tietz
    2012-05-10

    • status: open-works-for-me --> closed-fixed
     
  • Kai Tietz
    Kai Tietz
    2012-05-10

    Ok fixed at revision 4993 at trunk.