Re: RFC: need help with patch to check asm_fprintf format specifiers

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

 > From: "Joseph S. Myers" <jsm28@cam.ac.uk>
 > 
 > On Thu, 22 May 2003, Kaveh R. Ghazi wrote:
 > 
 > Ugliness is a bug, both in code and in extension design (and it's
 > extension design which is being done here).  An ad hoc mechanism for
 > passing types in at runtime (as opposed to carefully-designed general
 > syntax for extensible checking) would just make application-specific
 > checks uglier.

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.


 > > This is neither fair to me nor terribly efficient from a coverage
 > > perspective.  It makes more sense to leverage this across the larger
 > > set of gcc testers.  It's especially important going forward since
 > > it'll >prevent< new bugs from being introduced.
 > 
 > There are any number of checks that detect bugs that some people sometimes
 > do - building with extra --enable-checking options, building with
 > valgrind, ad hoc grepping for this or that problem, ....  It doesn't mean
 > that they are all appropriate for default bootstraps of GCC, even if that
 > would prevent some bugs.

The extra checks you cite have good reasons to limit them out of
default bootstraps.  Namely, they slow down bootstraps enormously, or
they require specific knowledge, or both.  My proposal doesn't have
these problems, it simply points out errors at compile-time without
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.

If you want to take shots at someone's efforts, you should at least
offer something of your own that is demonstrably better.  I'd be happy
to (constructively) critique your approach and work together towards
something we can all be happy with.  But you have to step up yourself.

 > New bugs in diagnostics that would be detected this way should be very
 > rare indeed, since any new diagnostic is expected to come with full
 > testcases.  The bugs should just be in old diagnostics that aren't yet
 > covered by the testsuite.

When the new C++ parser went in, there were a number of bugs that were
traced to bad format specifiers for functions that don't have
attributes.  It's very likely that some bugs remain but we simply
don't have full coverage in the testsuite.  I expect future large
merges will have the same problem.

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.

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