This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c/47781] warnings from custom printf format specifiers


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]