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

["philipp_subx@redfish-solutions.com" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #10 from Philip Prindeville <philipp_subx@redfish-solutions.com> ---
On Aug 21, 2014, at 11:06 AM, joseph at codesourcery dot com
<gcc-bugzilla@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781
> 
> --- Comment #9 from joseph at codesourcery dot com <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 <philipp_subx@redfish-solutions.com> ---
>> (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.
> 

Yeah, I agree: if the notation is adequate, all existing formats should be
expressible using it.