This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]