This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH]: Proof-of-concept for dynamic format checking
- From: "Kaveh R. Ghazi" <ghazi at caipclassic dot rutgers dot edu>
- To: ian at airs dot com
- Cc: gcc at gcc dot gnu dot org, joseph at codesourcery dot com
- Date: Wed, 17 Aug 2005 22:01:23 -0400 (EDT)
- Subject: Re: [PATCH]: Proof-of-concept for dynamic format checking
- References: <200508111509.j7BF9qMq015700@caipclassic.rutgers.edu>
> 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