[PATCH]: Proof-of-concept for dynamic format checking

[Kaveh R. Ghazi]

 > To make this kind of thing useful, I see two paths that we can follow.
 > The first is to simply not try to implement all of printf in a special
 > language.  Most printf extensions are not nearly as complex as printf
 > itself.  In fact, most simply add a few additional % conversions, with
 > no modifiers.  So we can get pretty good mileage out of a mechanism
 > which simply says "like printf, plus these conversions".

I like having a shorthand, however looking at the GCC sources custom
formats many of them want something much simpler than printf but with
several extra flags.

For example, gcc's asm_fprintf format implements "l" long and "ll"
long long as length modifiers, plus an extension "w" for gcc's
HOST_WIDE_INT.  However it does not implement C90 "h" or the C99 or
GNU extention length modifiers (e.g. "z" or "Z" for size_t).

Ditto for the gcc diagnostic formats.

Specifiers themselves are also a mixed bag.  The asm_fprintf format
doesn't implement %p or the floating point specifiers.  But of course
it has a bunch of it's own extension flags.

So clearly many implementations will need a language to specify
exactly what they do.

Alternatively or maybe in addition, we could have a way to say "like
printf, but delete these specifiers, and these modifiers.  Then add
these other things."  Ultimately if a complete language is available
as well as "like printf" then users will do whichever is easier given
their particular format.

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu