[cfe-dev] [PATCH] Let __attribute__((format(…))) accept OFStrings

[Jean-Daniel Dupas]

Le 27 nov. 2013 à 16:34, Jonathan Schleifer <js at webkeks.org> a écrit :

> Am 27.11.2013 um 10:49 schrieb David Chisnall <David.Chisnall at cl.cam.ac.uk>:
> 
>> I would love to see the printf attribute code generalised so that we could have a pragma to declare a formatting character and the type it expected.  For the FreeBSD kernel, we have a set of printf extensions for printing complex data structures, and a lot of modern libc implementations provide a mechanism for registering handlers for format strings.  It would be great if all of these could be supported, without hard-coding them.
> 
> I have to agree, a #pragma would be even better. I have to admit, I only thought about an option and not a pragma and using options, this would have become very ugly. But pragmas actually are a nice solution.
> 
> But there are a few questions left:
> Will the pragma allow it for all format specifier types? Will it only add them to a specific format specifier type?
> 
> I would suggest to have several pragmas, e.g.:
> #pragma clang format type(formatStringType, type)
> #pragma clang format add(formatStringType, formatSpecifier, type)
> 
> This would solve both problems for me: Adding OFString as a valid type for a format string and adding the specifiers. So I could use this:
> 
> #pragma clang format type(__OFString__, OFString)
> #pragma clang format add(__OFString__, "C", of_unichar_t)
> #pragma clang format add(__OFString__, "S", const of_unichar_t)

Having a custom type is meaningless if clang can't interpret it as a literal string at compile time, as it would not be able to check the format argument.
How are you planning to tell clang how to interpret a custom type into a string literal ?

> The hard part would be that the format specifier actually needs to be parsed so that something like this would also be possible:
> #pragma clang format add(printf, "llc", char32_t)
> 
> Any thoughts about this? I think this would be great and better than hardcoding it. I think this would be a solution to make everybody happy. I'd start writing a patch myself right away, but I think I am not enough into the internals of Clang yet ;). I'll see what I can do, but it might take a while due to limited time. If someone else also likes this, feel free to go ahead and do it, you'll most likely have something useful before I do ;).
> 
> Another benefit of this approach: Getting rid of all non-standard specifiers in Clang. glib and Apple could add their extensions in their system headers using those pragmas then.



-- Jean-Daniel