This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Special handling of "%H" (Re: Support for %d$c format specifierin diagnostics.c)
Ishikawa <ishikawa@yk.rim.or.jp> writes:
> But I would like to point out the subtle problem in anyway below.
> I was trying to write a one paragraph memo for future GCC po
> translators,
> and realized this subtle problem.
> Let me explain using the iterim memo.
...
>
> So if you ever need to refer to the FIRST %H in the message
> using positinal parameter as explained in my
> previous post, we need to make text_specifies_location at least
> understand that %1$H is equivalent to %H.
> Correct? (Otherwise the location information is not extracted
> and as we observed, the output would become different.)
Definitely with you so far.
>
> But if we let text_specifiers_location to eats up the
> %1$H string as well as %H,
> we may end up with the following scenario.
>
> warning ("%H'%D' might be used uninitialized in this function",...)
> -> Suppose for a gedanken experiment, someone needed to
> refer to the argument with positional parameter notation
> albeit the fact that we have only TWO arguments here.
> So that someone prepares the following translation.
> "%1$H'%2$D' might be used uninitialized in this function",
> -> So this is substitued in diagnostic->message.format_spec =
> _(msgid);
> -> Now this format_spec is passed to the now modified
> text_specifies_loation() that eats up %1$H.
> -> diagnostic->message.format_spec now becomes
> "'%2$D' might be used uninitialized in this function"
>
> -> Problem. pp_format_text() complains.
> The positional argument support mechanism complains
> that there is NO reference to the first argument since
> the only reference %2$D starts at the second argument.
> (We now don't see %1$H.)
Oops. That is a serious problem. This _will_ come up in cases where
there are two parameters plus a leading %H, so we need to get it fixed.
I suggest you try implementing the algorithm I outlined in my previous
message, which avoids this problem entirely, by eliminating the need
for text_specifies_location; pp_format_text is responsible for
processing the leading %H. Then it is no trouble at all to do the
right thing with %1$H there.
We do not have established lines of communication with the Translation
Project, so I do not want to try to explain to the translators that
they need to ignore the %H and count from the next argument. I'd
rather have a technical solution that lets them do as they are
accustomed. We'll have to tell them _somehow_ that a leading %H needs
to stay put (possibly getting turned into %1$H) but that is much
easier to convey.
zw