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

[Ishikawa]

"Joseph S. Myers" wrote:

> > It seems to me ONCE we use the %n$ construct,
> > we probably need to use this format from this point on always.
> > (Or we need to use this form for ALL the format specifiers.)
> 
> It must be used for _all_ specifiers that convert arguments, or _none_ of
> them.  (%% and %m, which don't convert arguments, can of course be mixed
> with %n$.)  This includes width and precision specifications: if %n$ is
> used then *n$ must be used rather than plain * for getting width or
> precision from an argument (and vice versa).  Also, if the nth argument is
> used then all the previous ones must be since we otherwise don't know
> their types to get to the nth argument.  The relevant paragraph is:

The use of *n$ for width specification was overlooked.
I have to think hard for this.
The current code in diagnostics.c really hard-wires the
use of the following argument for width, and so I must
probably rewrite that part in a radical manner.
 
>      The format can contain either numbered argument conversion
>      specifications (that is, "%n$" and "*m$"), or unnumbered argument
>      conversion specifications (that is, % and * ), but not both. The
>      only exception to this is that %% can be mixed with the "%n$" form.
>      The results of mixing numbered and unnumbered argument
>      specifications in a format string are undefined. When numbered
>      argument specifications are used, specifying the Nth argument
>      requires that all the leading arguments, from the first to the
>      (N-1)th, are specified in the format string.

Thank you for clarifying my question completely.
I wish the SUS documents give better examples on this matter, though.
Anyway, one major hurdle is now overcome.

> I recommend aborting if either of these constraints isn't met at runtime,
> at least if ENABLE_CHECKING.  (Once %n$ is implemented in diagnostic.c, a
> possible future project would be to write a checker for the .po files that
> makes sure that the source and translated strings are consistent, so that
> bugs in them can be reported to the translation teams and fixed, rather
> than waiting for someone to come across them at runtime.)
> 
> >       Before setting, we should check the double definition
> >       (which is OK?) and incompatible double definition, etc..
> 
> It is OK to use the same argument more than once, provided that the same
> type is used in each case (or a few other cases - formatting an argument
> with both %1$d and %1$u would be OK if the value has zero sign bit - but I
> don't think there's any need to allow such variations in diagnostic.c).
> (In fact I doubt there's much use in GCC for using arguments multiple
> times, and Bruce Korb has pointed out that glibc is broken with regard to
> doing so.)

I will keep these things in mind when I write the new code to
implement the feature.

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