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

["egall at gwmail dot gwu.edu" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781

Eric Gallager <egall at gwmail dot gwu.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egall at gwmail dot gwu.edu

--- Comment #15 from Eric Gallager <egall at gwmail dot gwu.edu> ---
(In reply to Tom Tromey from comment #11)
> ...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.

Wow, this is pretty much the same syntax I imagined when coming across this
issue independently! Except in my idea, I changed the name of the format
attribute to "printf-extended", to make it more obvious what the extra
arguments are. The case where I came across it was in trying to build a forked
old version bfd with -Wsuggest-attribute=format and -Wformat=2, where I was
unable to attach a format attribute to the bfd_error_handler_type declaration.
This is because _bfd_default_error_handler is extended to accept 2 new format
specifiers: %A, which takes args of type asection*, and %B, which takes args of
type bfd*. Using an attribute as proposed above, it'd be simple to just write
something like,

__attribute__((format(printf-extended, 1, 2, "A", asection*, "B", bfd*)))

Although checking the commentary on newer mainline versions of the
_bfd_default_error_handler function, it looks like it does some additional
weird stuff with the argument order, but still, support for extending the
format attribute like this would still be a good start!