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

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

Zack Weinberg wrote:
> 
> 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.

Hi,

I understand your concern of having to explain
the special handling of %H to PO translators.
Your point is well taken.

However, 

 - we also need to make sure to tell them that
   GCC uses its own extended format character set including
   %H after all anyway. (I am not sure if this has been
   understood by PO community.)	

 - We probably need to make sure that they understand the
   positional parameter usage, also.

Another fact is favoring simple approach.
Luckily, there are only about a dozen messages that

 - has %H at the beginning, and
 - has three or more % (percent signs) in it.
(I attach them below at the end.)

And so, I think unless such messages will multiply somehow quickly,
the problem should be manageable with a short warning to PO community
initially (Maybe I am too optimistic.)

Gabriel Dos Reis has followed up with the idea of going with this
warning and rule announcement for now, and modify the strings (and
hopefully remove this restrictive rule) once we implement better
algorithm in the future (I have no idea when).

Given the trouble of coming up with a good improved implementation to
satisfy all current needs, I tend to concur with Gabriel's idea.
Preliminary introduction of  positional parameter has uncovered
this subtle problem and we may see more problems along the way.

I will favor the merit of positional parameter introduction in general
and will live with the special caution for the dozen messages for now.

Now I will study your suggestion about the protocol between
pretty-print.c and custom format decoder.  But albeit the fact that
your suggestion is attractive in that there is less number of
interactions with
custom decoder than  my current suggested patch, I am not sure if your
suggested implementation can get rid of this problem of %H handling
here unless a major surgery is done in diagnostic.c framework somehow.

So for now, I will favor the simple approach of announcing the rule and
live with it. From this mailing list,  I have learned that
we have to fix many other PO strings
anyhow and a minimum interaction with PO community seems to 
be unavoidable anyhow. 

Any thoughts/comments from others?

Happy Hacking,

Ishikawa, Chiaki


PS: Strings that might cause problems:

sh check-num-percent.sh (<- this looks for such messages by looking for
	`"%H' and then count % signs in the line and print
	lines with three or more %  signs in it.


  ./gcc/c-decl.c:1129:		  error ("%Hprototype for '%D' follows and argument %d "
  ./gcc/c-decl.c:6451:	    warning ("%Hsize of return value of '%D' is %u bytes",
  ./gcc/c-decl.c:6454:	    warning ("%Hsize of return value of '%D' is larger than %wd bytes",
  ./gcc/dwarfout.c:2039:      warning ("%Hinternal regno botch: '%D' has regno = %d\n",
  ./gcc/stor-layout.c:518:	    warning ("%Hsize of '%D' is %d bytes",
  ./gcc/cp/call.c:2346:    inform ("%H%s %+#D <near match>",
  ./gcc/cp/call.c:2349:    inform ("%H%s %+#D",
  ./gcc/java/decl.c:1503:	warning ("%HIn %D: overlapped variable and exception ranges at %d",
  ./gcc/objc/objc-act.c:3500:  error ("%H%s `%s'", &DECL_SOURCE_LOCATION (decl),
  ./gcc/objc/objc-act.c:7050:  warning ("%H%s `%c%s'", &DECL_SOURCE_LOCATION (method),

  ./libstdc++-v3/config/locale/generic/time_members.cc:64:      _M_data->_M_time_format = "%H:%M:%S";
	  and other date string references. (These are not 


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