https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781
--- Comment #10 from Philip Prindeville ---
On Aug 21, 2014, at 11:06 AM, joseph at codesourcery dot com
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781
>
> --- Comment #9 from joseph at codesourcery dot com dot com> ---
> On Thu, 21 Aug 2014, philipp_s...@redfish-solutions.com wrote:
>
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781
>>
>> --- Comment #8 from Philip Prindeville
>> ---
>> (In reply to jos...@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.
