Summary: | on mingw __attribute__ ((__format__ (__printf__, ...))) doesn't recognize C99 specifiers | ||
---|---|---|---|
Product: | gcc | Reporter: | Nikita Kniazev <nok.raven> |
Component: | target | Assignee: | Not yet assigned to anyone <unassigned> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | egallager, lukaszcz18, peter0x44 |
Priority: | P3 | Keywords: | diagnostic |
Version: | 13.2.0 | ||
Target Milestone: | --- | ||
See Also: |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130 https://github.com/brechtsanders/winlibs_mingw/issues/233 |
||
Host: | Target: | *-w64-mingw32 | |
Build: | Known to work: | ||
Known to fail: | Last reconfirmed: |
Description
Nikita Kniazev
2024-04-18 20:48:21 UTC
So there is mingw_printf and gnu_printf attributes for mingw because at one point %ll didn't exist for mingw and nobody has updated it since then. (In reply to Andrew Pinski from comment #1) > So there is mingw_printf and gnu_printf attributes for mingw because at one > point %ll didn't exist for mingw and nobody has updated it since then. Sorry I mean ms_printf rather than mingw_printf. Anyways this is all documented: https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Common-Function-Attributes.html#index-format-function-attribute If anything gnu_printf should be used instead for _bfd_error_handler and that would be a binutils issue and reported there ... This is documented this way. If you want to use C99 printf format, you need to use gnu_printf instead (note gnu_printf format is for all targets and not just mingw). > So there is mingw_printf and gnu_printf attributes for mingw because at one point %ll didn't exist for mingw and nobody has updated it since then. Do you mean that binutils and [other code out there](https://github.com/search?q=%2F__attribute__%5Cs*%5C%28%5Cs*%5C%28%5Cs*_*format_*%5Cs*%5C%28%5Cs*_*printf%2F&type=code) should be updated to use gnu_printf in attributes? That would be a lot of work, clang doesn't know gnu_printf, and is wrong for actual printf wrappers. (In reply to Nikita Kniazev from comment #5) > > So there is mingw_printf and gnu_printf attributes for mingw because at one point %ll didn't exist for mingw and nobody has updated it since then. > > Do you mean that binutils and [other code out > there](https://github.com/ > search?q=%2F__attribute__%5Cs*%5C%28%5Cs*%5C%28%5Cs*_*format_*%5Cs*%5C%28%5Cs > *_*printf%2F&type=code) should be updated to use gnu_printf in attributes? > That would be a lot of work, clang doesn't know gnu_printf, and is wrong for > actual printf wrappers. This has been documented/implemented this way for ~16 years now (for GCC 4.4.0), r0-86297-g6590fc9fbd071d . https://inbox.sourceware.org/gcc-patches/OF604F1098.0E3FE32A-ONC1257408.003BB78C-C1257408.003CE7F2@onevision.de/ (In reply to Andrew Pinski from comment #6) > (In reply to Nikita Kniazev from comment #5) > > > So there is mingw_printf and gnu_printf attributes for mingw because at one point %ll didn't exist for mingw and nobody has updated it since then. > > > > Do you mean that binutils and [other code out > > there](https://github.com/ > > search?q=%2F__attribute__%5Cs*%5C%28%5Cs*%5C%28%5Cs*_*format_*%5Cs*%5C%28%5Cs > > *_*printf%2F&type=code) should be updated to use gnu_printf in attributes? > > That would be a lot of work, clang doesn't know gnu_printf, and is wrong for > > actual printf wrappers. > > This has been documented/implemented this way for ~16 years now (for GCC > 4.4.0), r0-86297-g6590fc9fbd071d . > > https://inbox.sourceware.org/gcc-patches/OF604F1098.0E3FE32A-ONC1257408. > 003BB78C-C1257408.003CE7F2@onevision.de/ Which attributes should use for void my_printf(const char *fmt, ...) { va_list ap; va_start(ap, fmt); printf(fmt, ap); va_end(ap); } so it will behave correctly with any combination of -std=c89, -std=c99, __USE_MINGW_ANSI_STDIO=0, __USE_MINGW_ANSI_STDIO=1, _UCRT (In reply to Nikita Kniazev from comment #7) > (In reply to Andrew Pinski from comment #6) > > (In reply to Nikita Kniazev from comment #5) > > > > So there is mingw_printf and gnu_printf attributes for mingw because at one point %ll didn't exist for mingw and nobody has updated it since then. > > > > > > Do you mean that binutils and [other code out > > > there](https://github.com/ > > > search?q=%2F__attribute__%5Cs*%5C%28%5Cs*%5C%28%5Cs*_*format_*%5Cs*%5C%28%5Cs > > > *_*printf%2F&type=code) should be updated to use gnu_printf in attributes? > > > That would be a lot of work, clang doesn't know gnu_printf, and is wrong for > > > actual printf wrappers. > > > > This has been documented/implemented this way for ~16 years now (for GCC > > 4.4.0), r0-86297-g6590fc9fbd071d . > > > > https://inbox.sourceware.org/gcc-patches/OF604F1098.0E3FE32A-ONC1257408. > > 003BB78C-C1257408.003CE7F2@onevision.de/ > > Which attributes should use for > > void my_printf(const char *fmt, ...) > { > va_list ap; > > va_start(ap, fmt); > printf(fmt, ap); > va_end(ap); > } > > so it will behave correctly with any combination of -std=c89, -std=c99, > __USE_MINGW_ANSI_STDIO=0, __USE_MINGW_ANSI_STDIO=1, _UCRT that is a good question but that is a question for the mingw forums really rather than inside gcc bugzilla. Ok, is there at least an option to build GCC so it defaults __printf__ to gnu_printf? Defaulting __printf__ to ms_printf on UCRT is wrong (every OS without UCRT is already EOL). (In reply to Nikita Kniazev from comment #9) > Ok, is there at least an option to build GCC so it defaults __printf__ to > gnu_printf? Defaulting __printf__ to ms_printf on UCRT is wrong (every OS > without UCRT is already EOL). There is none yet. But any fix won't happen until GCC 15 really ... -mcrtdll=ucrt should make __printf__ be gnu_printf instead of ms_printf. Should I file separate issue or this one can be reopened? (In reply to Nikita Kniazev from comment #11) > -mcrtdll=ucrt should make __printf__ be gnu_printf instead of ms_printf. > Should I file separate issue or this one can be reopened? The reality is ms_printf most likely should just include z and ll support instead since they are supported now: https://learn.microsoft.com/en-us/cpp/c-runtime-library/format-specification-syntax-printf-and-wprintf-functions?view=msvc-170 They have been included since 2015. As I mentioned GCC mingw support is out of date really and should be fixed there . (In reply to Andrew Pinski from comment #12) > The reality is ms_printf most likely should just include z and ll support > instead since they are supported now: > https://learn.microsoft.com/en-us/cpp/c-runtime-library/format-specification- > syntax-printf-and-wprintf-functions?view=msvc-170 While it makes sense, if ms_printf and gnu_printf will behave the same - there is no point in having them then. (In reply to Andrew Pinski from comment #12) > As I mentioned GCC mingw support is out of date really and should be fixed there . Fixed where? IIUC the machinery is in gcc/config/i386/msformat-c.cc *** Bug 116232 has been marked as a duplicate of this bug. *** |