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

[Ishikawa]

Zack Weinberg wrote:
> 
> Ishikawa <ishikawa@yk.rim.or.jp> writes:
> > --- 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.
> 
> There are not supposed to be any such entry points.  All of the
> strings that are deliberately not translated, do not go through
> diagnostic.c.  Everything that diagnostic.c prints is supposed to
> be subject to translation.
> 
> > 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.
> 
> You're correct that debugging dumps do not need translation, but
> they use their own printers, so you needn't worry about it.
> 
> Tracing through diagnostic.c can be confusing.  There is a convention
> that may help: A function with an argument 'const char *msgid' has
> responsibility for getting the string translated.  This may happen
> either by a direct call to gettext (which may be written using a
> shorthand macro: _(msgid)), or by passing the string to another
> function which will take responsibility.
> 
> In diagnostic.c, the buck stops (mostly) with diagnostic_set_info.
> 
> Another convention which is much less widely used: a function with
> an argument 'const char *msgstr' expects to receive a string that
> has already been translated.
> 
> More generally, string variables named 'msgid' are intended to be
> translated, but haven't yet, and string variables named 'msgstr' have
> already been translated.
>

Thank you for the clarification.
I must have missed this info (written somewhere?).

Will hack the rest of the code soon.


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