This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Support for %d$c format specifier in diagnostics.c
"Kaveh R. Ghazi" wrote:
>
> > From: Ishikawa <ishikawa@yk.rim.or.jp>
> >
> > - Positional parameters such as %1%s are unlikely to occur in
> > source files. (We could even prohibit the use in the SOURCE files
> > if necessary. Maybe too harsh. )
> > If this is true, then the format checker can, for now, defer the
> > checking of positional paramters.
>
> IMHO, you can't say "unlikely" or "maybe". GCC bootstraps itself with
> -Werror, so if even one such instance occurs in it's own source, then
> we have to update the format checker to accept it or we'll get a
> warning-error which will halt bootstrap.
>
> OTOH, if we go through the effort to make the format checker aware of
> these, then you don't have to discourage using it. You can feel free
> to use it exactly as much as you feel is necessary.
Thank you for your comment.
I studied the patch mentioned in one of your previous posts.
> For the particular patches, see:
> http://gcc.gnu.org/ml/gcc-patches/2003-06/msg02515.html
> http://gcc.gnu.org/ml/gcc-patches/2003-07/msg00366.html
Yes, for the format checker,
I will use the data definitions, etc. as implemented in your patch, but
I am not quite sure how to accommodate the
positional parameter in the checker framework.
In the meantime, a separate tool msgfmt (for gettext suite, I think)
might be enhanced to understand GCC extensions so that
translated strings (dynamically substituted) and the original static
strings match in the argument usage. (But I have to find out if it
supports positional paramters by downloading the latest version. My
local version doesn't have --check-format option yet.)
But please don't hold your breath at this moment.
My plan is
- (1) first to incorporate the C++, and C extension into the positional
paramter handling framework by extending the
protocol between the decoder and diagnostic.c.
This is necesary for the positional parameter handling to
be usable.
- (2) Then I can take a look at enhancing the checking tool.
This will ensure the relatively bug-free format string usage.
This will include
(2-1) - take a look at msgfmt as a separate tool for checking
PO files. Also study the possibility of
creating a new tool for GCC PO checks since
GCC adds a few extensions.
(Again, this checking is done for consistency between the
original format string and the translated string.
There seem to be many errors according to the post by
Wolfgang Bangerth.
Copatibility checking between the original format string
in the source file and argument lists passed is done
by the following.)
(2-2) - study the existing internal check framework
and see how the positional paramter
can fit in the framework.
Until (2-2) is done and support for positional paramter checking
is in the format string framework, anyone trying to use
positional parameter in the original string in GCC source files
will be asked to rewrite it.
(PO files can use them freely.)
Once the format checking for positional parameter is in place,
it can be used everywhere.
However, we have a limited man-power obvioulsy.
>From the discussion here, I have a feeling that
current C front ends doesn't support checking of
postional paramters for format string correctness. Am I right?
(If so, we might want to postpone (2-2) until
the generic framework for format check processing is requested
to handle positional paramter very much.)
As of now, there is a demand for positional paramter for I18N/L10N
work as suggesed by Wolfgang.
Positional parameter format checking in the SOURCE code can wait.
It is just a matter of where to put the man-power first.
Thank you again for your tips and suggestions.
Happy Hacking,
Ishikawa, Chiaki
--
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */