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

[Ishikawa]

Hi,

> I'm supportive of your work. Please make sure we don't tangle each
> other on the reorganization of diagnostic.[ch], c-pretty-printer,
> cp/cxx-pretty-print.c and cp/error.c

Thank you for your kind words.

I am in the process of modifying the diagnostic.[ch] to remove
static variables that I introduced in the proposed patch, and
introducing the necessary bridge between output_format() and
custom decoders. (As of now c_objc_common.c has been modified locally
and being
tested..).

Not that this is targeted to you only, but are we on the same wavelegnth
as regard to the following paragraphs in 
gcc/gcc/ABOUT-GCC-NLS ?

--- begin quote from ABOUT-GCC-NLS ---
Not all of GCC's diagnostic messages have been internationalized.
Programs
like `genattr' (in fact all gen* programs) are not internationalized, as
their users are GCC maintainers who typically need to be able to read
English anyway; internationalizing them would thus entail needless work
for
the human translators. Messages used for debugging, such as used in
dumped
tables, should also not be translated.

The GCC library should not contain any messages that need
internationalization, because it operates below the internationalization
library.

Unlike some other GNU programs, the GCC sources contain few instances
of explicit translation calls like _("string").  Instead, the
diagnostic printing routines automatically translate their arguments.
For example, GCC source code should not contain calls like `error
(_("unterminated comment"))'; it should contain calls like `error
("unterminated comment")' instead, as it is the `error' function's
responsibility to translate the message before the user sees it.

--- end quote ---

I am not sure if the tree printing routines require I18N/L10N.
I agree witht the first two paragraphs in the quotes. 

After reading the third paragraph in the above quote, 
I am not sure if there are entry points in diagnostic.c which
do  NOT use the translation and end up with output_format() with
the original format string intact.
But I guess there must be such entry points.
Such usage of output_format() won't need positional parameters.
I have a feeling that tree dump and RTL dump(?) won't need
such translation either.

Am I missing something here?

Again, this is not directed to you only, but
I wonder if the developer community has a shared opinion.

PS: the change to c-objc-common.c is benign in the sense that
it doesn't seem to break anything as long as we don't use
positional parameters.
(This is a good thing.)
I am running "make -k check" at the top level, after
bootstrapping on x86 Debian GNU/Linux and will
begin hacking cp/error.c in a day or two.
When it bootstraps locally and pass make -k check,
I will pass the next cut of the patch.

PO files checking can wait. Installing gettext() seems to
be rather convoluted and time consuming. At least, I needed
to upgrade automake to certain version, and then I gave up
in the midway. No wonder PO files may not see
through checking as made possible by the latest msgfmt if
installing the latest msgfmt is hard, but I digress.

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