From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106689 invoked by alias); 21 Sep 2015 19:16:24 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 106651 invoked by uid 48); 21 Sep 2015 19:16:20 -0000 From: "egall at gwmail dot gwu.edu" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/47781] warnings from custom printf format specifiers Date: Mon, 21 Sep 2015 19:16:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 4.4.5 X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: egall at gwmail dot gwu.edu X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-09/txt/msg01737.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781 Eric Gallager changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |egall at gwmail dot gwu.edu --- Comment #15 from Eric Gallager --- (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!