This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/47781] warnings from custom printf format specifiers
- From: "tromey at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 29 Jan 2015 16:42:39 +0000
- Subject: [Bug c/47781] warnings from custom printf format specifiers
- Auto-submitted: auto-generated
- References: <bug-47781-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781
Tom Tromey <tromey at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tromey at gcc dot gnu.org
--- Comment #11 from Tom Tromey <tromey at gcc dot gnu.org> ---
(In reply to joseph@codesourcery.com from comment #4)
> For the general issue, my inclination is that we should add plugin hooks
> into the format checking machinery that allow plugins to define formats
> with the full flexibility of all the format checking datastructures in
> GCC.
I agree this makes sense for the general case, but I wanted to point out
that requiring a plugin for the simple cases is significantly harder for
users than some in-source extension mechanism.
E.g., firefox has a logging printf that accepts "%hs" to print char16_t*
strings. This extension means that printf checking can't be used here.
Requiring a plugin to deal with this situation would also be difficult.
However letting one write __attribute__((printf, 1, 2, "hs", char16_t*))
would solve this nicely.
I suppose I think that a format-for-a-specific-type is the most common
kind of extension and so may deserve special treatment.