On Fri, 10 Nov 2006, Nuno Lopes wrote:
> On Fri, 10 Nov 2006, Ian Lance Taylor wrote:
>
> > I kind of liked this idea:
> > http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00797.html
> > but of course it was insane.
>
> I still think a higher level state machine as described in the
> followups
> is how things should be done.
wouldn't that be killing a mosquito with a bomb? :) (unless of course we
can
find a simple description language)
Format checking is complicated. Over 5% of all the 40000 or so test
assertions in a gcc testsuite run are from format checking testcases.
Format checking is one of the most difficult parts of the compiler to get
correct from an i18n perspective (i.e. having all complete sentences
available for translation); everything else in the C front end apart from
parse errors should be correct in that regard.
Can I do anything to help? I mean, can you point me the files and what
should
I do in order to make this move forward? (the most I've made was a few
little
patches to make a customized cross-compiler to a mips robot, so I'm not
very
familiarized with the code...)
c-format.[ch]. Understand the logic in there as a whole. Consider what
aspects of information about format strings are embedded in the code and
how you might improve the datastructures, one aspect at a time, to
describe that aspect in data rather than code. For verifying there are no
unintended changes in the compiler's behavior, compare the exact
diagnostic texts in gcc.log from test runs before and after each change.