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: RFC: need help with patch to check asm_fprintf format specifiers

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.  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.

> 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.

Joseph S. Myers

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