Support for %d$c format specifier in diagnostics.c

[Ishikawa]

> | I will study this and see what I can do.
> | But I have a doubt if the checking of positional parameter
> | is of immediate necessity due to the following observation:
> | the positional construct is VERY UNLIKELY to be used
> | inside the GCC source files.
> 
> What that means is simply that if we wanted to check formats augmented
> with the positional thingy, then we should not check each individual
> toplevel diagnostic routines; instead we should have special code to
> check calls to report_diagnostic -- I'm not sure I want to head that
> way.

In a separate post.:

Gabriel Dos Reis wrote:

> | I posted a reply to Kaveh in which I mention that
> | this positional parameter such as "%1$s" is very unlikely to
> | appear in the SOURCE file, and mainly used inside PO files.
> 
> I agree with your statement.
> 
> However, the purpose of the format checker is to make sure that only
> valid format specifiers (and the right number of arguments) are given
> to the diagnostic formatter.  It would be desirable to maintain that
> property for translated strings also.

My current thinking was

 - It seems that we are going to have a format checker developed by
Kaveh.
   This checks the format string versus the actual argument used in
   the source files. (stage-1).

 - My current thiking is to check the translated strings inside PO files
   against the original strings for mismatches, etc. (stage-2).
  (This may have to be a separate tool. Also, the non-standard extension
   done by cp/error.c, etc. has to be supported.)

   The problem with the static checker is that it can NOT cover the
   translated strings since the substitution of the original format
   string takes place only during the execution of the program.

Combination of (stage-1) check AND (stage-2) check will ensure that
we have reasonably error-free format string usage. 

My premise is:
 - static source analysis tool can't check for the translated string,
which
   is fetched from PO files at runtime.
   (So we need a separate tool/framework  to check each PO file anyway.
    Sure we could extend the static tool to invoke gettext(), but
    it is impractical. We need to know which routines invoke
    translation and strings are substituted. We probably don't want to
    know the details for the analysis of the top-level routines.) 
 
 - 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.

Comment?

I am studing the effect of custom decoders and if the interaction of the
custom decoders and the proposed format checker is not complicated,
maybe such a test can be easily incorporated, but I have a doubt now.

PS:  BTW, I noticed that GCC can check the usage of format string versus
the
  actual parameters for fprintf(), sprintf(), etc. 
  Does the check support positional paramters as of now?
  (Support for positional parameter in glibc was mentioned and if so,
   it is being used more widely on open source platforms.).




-- 
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 */