Re: [PATCH, RFC] Extend __attribute__((format)) with user-specified conversion sequences
Hi, thanks for the reply.
On 4/8/12 6:25 AM, Joseph S. Myers wrote:
Character pairs like this don't seem very extensible, in that you are
providing meanings for any even-length string, rather than (for example)
only a limited subset of strings leaving room for meanings to be assigned
later to other strings.
Future extensions could use identifiers rather than strings, or other
syntax, but understood.
They also have the obvious problem of not covering application-specific
types as arguments, only types that have corresponding standard formats.
Agreed.
In principle we want extensibility of format checking, and want it to be
as flexible as the built-in checking is regarding the peculiarities of
different formats - but we also don't want to export implementation
details of format checking to users' source code, and the two points seem
rather to contradict each others. So my recent inclination has been that
we should make it possible for plugins to add new format checking types
(but the details of the relevant interfaces would be unstable, so such
plugins might need to change for each GCC version). That means a function
for a plugin to register a new format type - and probably a callback
called when that format type is used for a function declaration that can
look for a typedef name in the same way that the existing GCC-internal
formats are handled.
The plugin architecture would work great for format strings that are
very different from printf/scanf, but seems heavyweight for format
strings that are close to printf/scanf.
Would a better syntax for printf/scanf + extensions format strings be
worth accepting independent of plugins?
For instance:
__attribute__(printf, 1, 1, '' ('%'), ';' ('0'))
== treat '' like '%' and ';' like '0'
__attribute__(printf, 1, 1, '' (), 'F' (expr *))
== '' takes 0 arguments, 'F' takes an expr * argument in the list
Best,
Eddie
Re: [PATCH, RFC] Extend __attribute__((format)) with user-specified conversion sequences
On Sat, 31 Mar 2012, Eddie Kohler wrote: The syntax is very simple. The extra argument, an even-length C string constant, is interpreted as a set of character pairs. For example, % says interpret the character '' like you would '%': as a conversion specifier that consumes no arguments from the argument list. Ad says interpret 'A' like 'd': as a conversion specifier that consumes an int. %%,%;0 says '', '', and ',' are zero-argument conversion specifiers, and ';' is a flag like '0'. This is actually pretty flexible, simple to implement, and suffices for my use (the Click modular router). Perhaps you see obvious ways I could improve it? A full-fledged little language for format string definitions seems like too much work for now, unfortunately, but the character-pair syntax could be extended later. Character pairs like this don't seem very extensible, in that you are providing meanings for any even-length string, rather than (for example) only a limited subset of strings leaving room for meanings to be assigned later to other strings. They also have the obvious problem of not covering application-specific types as arguments, only types that have corresponding standard formats. In principle we want extensibility of format checking, and want it to be as flexible as the built-in checking is regarding the peculiarities of different formats - but we also don't want to export implementation details of format checking to users' source code, and the two points seem rather to contradict each others. So my recent inclination has been that we should make it possible for plugins to add new format checking types (but the details of the relevant interfaces would be unstable, so such plugins might need to change for each GCC version). That means a function for a plugin to register a new format type - and probably a callback called when that format type is used for a function declaration that can look for a typedef name in the same way that the existing GCC-internal formats are handled. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH, RFC] Extend __attribute__((format)) with user-specified conversion sequences
On Apr 8, 2012, at 3:25 AM, Joseph S. Myers wrote: In principle we want extensibility of format checking, and want it to be as flexible as the built-in checking is regarding the peculiarities of different formats - but we also don't want to export implementation details of format checking to users' source code, and the two points seem rather to contradict each others. So my recent inclination has been that we should make it possible for plugins to add new format checking types (but the details of the relevant interfaces would be unstable, so such plugins might need to change for each GCC version). Longer term, we can hope that the interface evolves into something stable and pretty. For the plugin people that don't want the interface churn, a little time now in this area hopefully would translate into longer term stability.
