Special handling of "%H" (Re: Support for %d$c format specifier in diagnostics.c)

[Ishikawa <ishikawa at yk dot rim dot or dot jp>]

I was testing my proposed support for positional format specifier
when custom format decoder is invoked, and I noticed
a somewhat surpriseing special handling of %H at the
beginning of a warning message.

Is the %H at the beginning of an error/warning message handled in a
special manner by routines in diagnostic.c?

Background:

I was testing my proposed patch for positional format specifier when
custom format decoder is invoked.  (I found that the code works as
expected after a minor tweak.  This itself is good.)

To do this, I needed calls to pp_format_text() that use extended format
characters.  So, for a start, I changed a warning message string in
function.c to use a positional paramter notation.  The message is near
line 5570 to invoke custom decoder in c-front-end.

	  && regno_uninitialized (REGNO (DECL_RTL (decl))))
	warning ("%H'%D' might be used uninitialized in this function",
	...

With a small C test source file that uses a variable uninitialized, I
get the compiler to print out the warning with the above line.

I changed the above message line  to read

 - warning ("'%2$D' might be used uninitialized in this function: %1$H :
MARKER",
 - warning ("%1$H'%2$D' might be used uninitialized in this function",


After the modification and ran the compilation, I noticed that the
format string passed to pp_format_text() is not quite what I expected.

It seems that somewhere during the processing after the invocation of
warning() and pp_format_text(), the heart of the formatting engine,  the
"%H" at the beginning of the message disappears.
However, "%1$H" at the beginning of the string obviously
is not understood by the mechanism that eats "%H" at the beginning.
So it remains and is passsed to pp_format_text().

So although I thought the follwoing two would produce similar message,
the two ended up with different output.
warning ("%H'%D' might be used uninitialized in this function", 
warning ("%1$H'%2$D' might be used uninitialized in this function",

I added a debug output to show the format string passed to
pp_format_text()
and ran the compilation to show what I described above.

Original case:

warning ("%H'%D' might be used uninitialized in this function", 
---> This would produce the output as follows.

    pp_format_text:<<function declaration isn't a prototype>>
    /tmp/test.c:3: warning: function declaration isn't a prototype
    pp_format_text:<<In function `%s':>>
    /tmp/test.c: In function `test':

    *** Below, please note that %H at the beginning disappeared. ***
    pp_format_text:<<'%D' might be used uninitialized in this function>>
    /tmp/test.c:4: warning: 'i' might be used uninitialized in this
function

modified case-1:
warning ("%1$H'%2$D' might be used uninitialized in this function",
--> This would produce the output as follows.

    pp_format_text:<<function declaration isn't a prototype>>
    /tmp/test.c:3: warning: function declaration isn't a prototype
    pp_format_text:<<In function `%s':>>
    /tmp/test.c: In function `test':

    *** Below, note that the string is passed as is, unmodified. ***	
    pp_format_text:<<%1$H'%2$D' might be used uninitialized in this
function>>
    /tmp/test.c:12: warning: file '/tmp/test.c', line 4'i' might be used
uninitialized in this function

    Note also, that locus handling code produced "file '/tmp/test.c',
line 4"
    as expected. (pp_format_text() could use additional space after
    the line number, maybe.)

modified case-2:
   I shuffled the specifiers around. The result is as expected. (good!).

warning ("'%2$D' might be used uninitialized in this function: %1$H :
MARKER",

    pp_format_text:<<function declaration isn't a prototype>>
    /tmp/test.c:3: warning: function declaration isn't a prototype
    pp_format_text:<<In function `%s':>>
    /tmp/test.c: In function `test':

    pp_format_text:<<'%2$D' might be used uninitialized in this
function: %1$H : MARKER>>
    /tmp/test.c:12: warning: 'i' might be used uninitialized in this
function: file '/tmp/test.c', line 4 : MARKER

So, the handling of extended format character using custom
format_decoder is working as far as the modified pp_format_text() is
concerned.  It handles the passed format string and invokes the custom
decoder as expected (!). Good.

Problem is that the special handling of "%H" at the beginning of the
message may get in the way of I18N/L10N.

Suppose some PO translators need to refer to arguments in a particular
message string using positional paramters (three or more format
specifications including %H), then this special handling of %H at the
beginning of a message ends up unexpected difference in output because
the translators need to put %1$H instead of %H at the beginning of the
translation string.  (If there no strings for which they have to use
positional parameters, then we have no problem.)

Now, I was afraid if such messages were abundant.

It turns out, in current C source code, there are several messages
that start with `"%H' and include three or more percent signs.

I list them up as follows and added comment.

The following two lines look manageable from the viewpoint of
Japanese translation. (But I don't know for other languages.).
./c-decl.c:	    warning ("%Hsize of return value of '%D' is %u bytes",
./c-decl.c:	    warning ("%Hsize of return value of '%D' is larger than
%wd bytes",

The next line in dwarfout.c probably should not use warning() since
this could be subject to translation? (I mean ABOUT-GCC-NLS mentions
that internal error message probably should be output in ASCII string
without translation for eventual inspection by the developer
community, which uses English mostly.)

./dwarfout.c:      warning ("%Hinternal regno botch: '%D' has regno =
%d\n",

The following looks manageable. (again I can't speak for other
langauges.) 
./stor-layout.c:	    warning ("%Hsize of '%D' is %d bytes",

I have no idea for what the following two lines are used.
(But, there are NOTHING to translate except for "<near match>" and
so probably the original order of reference to arguments
 could be preserved in translation.)
./cp/call.c:    inform ("%H%s %+#D <near match>",
./cp/call.c:    inform ("%H%s %+#D",

Ditto for these three lines. The latter two are impossible for
translation to work at diagnostic.c level.
The message given,  which seems to be stored in
the argument value somehow, must be translated PRIOR to this call. 
(I have no idea if such translation is done. Maybe it is, given the
many strings not meant for format strings.)

./java/decl.c:	warning ("%HIn %D: overlapped variable and exception
ranges at %d",
./objc/objc-act.c:  error ("%H%s `%s'", &DECL_SOURCE_LOCATION (decl),
./objc/objc-act.c:  warning ("%H%s `%c%s'", &DECL_SOURCE_LOCATION
(method),

Conclusion:

My conclusion is that we probably won't be affected much since the
number of problematic lines with three or more specifiers is rather
small, and these lines seem to be either amenable
to translation, or probably we won't need to translate them at all.

But we probably have to bear this potential problem caused
by the special handling of "%H" at the beginning of a diagnostic message
string in mind.