expanding __attribute__((format,..))

[Nuno Lopes]

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

OK, thanks for your tips. I'll take a look at it as soon as I have some free 
time (aka as soon as this university semester ends).

Nuno