https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89923
--- Comment #6 from Tom Honermann ---
(In reply to jos...@codesourcery.com from comment #5)
> We (GCC) don't control printf;
I know, by "we" I meant the C and C++ standards community.
> the format checking should match what the
> actual libc s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89923
--- Comment #5 from joseph at codesourcery dot com ---
On Fri, 5 Apr 2019, tom at honermann dot net wrote:
> To be clear, the position I'm suggesting is that we add support for something
> like these:
We (GCC) don't control printf; the format c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89923
--- Comment #4 from Tom Honermann ---
(In reply to Florian Weimer from comment #3)
> But the precedent with wchar_t is that the type of the format string
> determines the type of the %s arguments. I'm not sure if that's a good
> precedent, but i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89923
--- Comment #3 from Florian Weimer ---
But the precedent with wchar_t is that the type of the format string determines
the type of the %s arguments. I'm not sure if that's a good precedent, but
it's what we have today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89923
--- Comment #2 from Tom Honermann ---
I think my preferred fix to this is to introduce new length modifiers for the
"%s" conversion specifier for all of char8_t, char16_t, and char32_t.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89923
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89923
--- Comment #1 from Jonathan Wakely ---
Especially as the C++2a change breaks previously valid code:
printf("%s\n", u8"");
