This is the mail archive of the gcc-patches@gcc.gnu.org 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


 > From: "Joseph S. Myers" <jsm28@cam.ac.uk>
 > 
 > 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			ghazi@caip.rutgers.edu


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