This is the mail archive of the
mailing list for the GCC project.
Re: RFC: need help with patch to check asm_fprintf format specifiers
> From: "Joseph S. Myers" <firstname.lastname@example.org>
> On Thu, 22 May 2003, Kaveh R. Ghazi wrote:
> > Has the full featured extensible format checking been designed? I'd
> > like to see it, I really would. The current situation is a recipe for
> > doing nothing and making zero progress. The holy grail of extensible
> > format checking has been in the projects page for at least 2.5 years
> > in revision 1.1 of the projects index.
> It has not been designed: though I'd like to implement such a feature I've
> never had sufficient time available for working on GCC to consider
> starting its design and implementation, so all that has happened is the
> incremental changes to yield the data structures now present: everything
> is controlled by the data structures (not conditioned on format type) but
> some of the flags are extremely ad hoc for particular format features, and
> the present data structures are not suitable for exposing as an interface
> for extensible format checking.
> > any measurable slowdown. I agree it's not the final solution, but I
> > haven't seen any progress or even a design spec on whatever you
> > propose as as alternative.
> The progress was the move of the format checking to being controlled by
> data structures rather than ad hoc code: a specific aim of that was to
> move towards the possibility of extensible format checking.
Yes, that was a good step forward. Thanks.
> Although I can see roughly what the next step might be (moving
> details of the sequence of components of a specifier - %, width,
> precision, ... - out of code) the final state of the structures,
> and so the plausible interface to them, is not yet clear.
By interface, you mean programming internals or user-visible grammer?
Can you flesh out anything at all? E.g. if we agree on a complete
final grammer, perhaps as a first step I could implement just enough
of it to get %wd correctly specified. Then the extension is not
throw-away, its incremental but a "keeper".
> > Compile-time checks which offer complete coverage are so much better
> > than ad-hoc runtime tests. I find your reliance (preference?) for
> > runtime tests baffling. It's like preferring runtime tests on
> > function arguments over prototype compile-time checks.
> It's a preference against adding an extension specific to one application
> which it is intended to remove, to the mainline (and, more so, to
> releases); not to making the tests, or to having a branch with such
> extensions which is regularly merged and tested. Extensions generally
> cause trouble (in particular, the presumption must generally be against
> adding an extension until proven otherwise) and it's a subjective
> assessment of the aesthetics, value and cost of a particular extension
> being in mainline and released GCC.
Would it help if I wrapped my implementation in ENABLE_CHECKING? Then
no released version of the compiler would have this extension and you
wouldn't have to worry about supporting it.
Kaveh R. Ghazi email@example.com