From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17325 invoked by alias); 21 Aug 2014 17:07:03 -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 17252 invoked by uid 55); 21 Aug 2014 17:06:58 -0000 From: "joseph at codesourcery dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/47781] warnings from custom printf format specifiers Date: Thu, 21 Aug 2014 17:07: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: joseph at codesourcery dot com X-Bugzilla-Status: NEW 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: 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: 2014-08/txt/msg01478.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781 --- Comment #9 from joseph at codesourcery dot com --- On Thu, 21 Aug 2014, philipp_subx@redfish-solutions.com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781 > > --- Comment #8 from Philip Prindeville --- > (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. Using GCC plugins for this avoids problems with defining complicated > > syntax in the source file to describe the peculiarities of different > > formats, which might constrain future changes to the format checking > > implementation by making too much of the internals visible to user source > > code, because by design GCC plugins can use GCC internals which are free > > to change incompatibly in ways that require plugin changes. > > What about using pragmas to describe the new format specifier? Those have the issue of either being limited in the sorts of formats that can be described, or else exposing more internals than seems desirable to expose as a stable interface. Plugins allow full flexibility (with possible instability of interfaces), though a stable subset (e.g. formats that take no length modifiers or flags) could probably be defined that has a stable interface in source files (such as through attributes or pragmas) that doesn't unduly constrain the internals of the implementation. But I think any such stable interface would not be able to describe the full generality of the existing built-in formats. One interesting question would be whether a good stable interface can be defined that is general enough to describe GCC's internal formats - whether those are regular enough that a description isn't tied to hardcoded special cases or extremely complicated descriptions of what cases should / should not get warnings.