RE: New ARI warning Sat Aug 14 01:53:52 UTC 2010

["Pierre Muller" <pierre dot muller at ics-cnrs dot unistra dot fr>]

> From Vladimir Prus
> >> gdb/mi/mi-main.c:1512: code: sprintf: Do not use sprintf, instead
> use xstrprintf
> > gdb/mi/mi-main.c:1512:	  sprintf (p, ', read_result->data[i]);
The real source line is 
  sprint (p, "%02x", read_result->data[i]);
> This warning is bogus in this context. How do I silence it?

  Could you explain further why the message is bogus?
  I think the message should be enhanced to also propose
xsnprintf (char *str, size_t size, const char *format, ...)
as a valid substitute for 'sprintf' if the char array is already allocated.
Of course this always adds some overhead, but it ensures
that no overflow is happening.
  Is it a C specification, that "%02x" as a format string
will never use more than two bytes?
  If this is the case, we can silence the warning by adding
a /* ARI: sprintf */ comment on the same line.
otherwise use of 'xsnprintf' seems like an improvement to me.
 
> >> gdb/mi/mi-main.c:1490: gettext: _ markup: All messages should be
> marked up with _.
> > gdb/mi/mi-main.c:1490:    error ("Unable to read memory.");
> >> gdb/mi/mi-main.c:1582: gettext: _ markup: All messages should be
> marked up with _.
> > gdb/mi/mi-main.c:1582:    error ("mi_cmd_data_write_memory: Usage: [-
> o COLUMN_OFFSET] ADDR FORMAT
> > WORD-SIZE VALUE."); 821a825
> >> gdb/mi/mi-main.c:1738: gettext: _ markup: All messages should be
> marked up with _.
> > gdb/mi/mi-main.c:1738:    error ("the specified thread group does not
> exist");
> 
> Of above warnings, only first appears to be added by a recent patch of mine,

  The script I wrote to try to isolate new warnings is far from
perfect and I warned that there could be also false warnings appearing.
My knowledge of AWK is still too limited to really write something better, sorry.

> while others were there all the time. That said, have we ever decided if MI
> should try to i18n its error messages? At least some of messages, like
> "Unable to read memory" above, can probably be shown to user -- except it's
> so generic as to be useless. Some messages, clearly, indicate frontend
> bugs and showing them to users, or l10n-ing, makes no sense.

  If it is decided that most mi code should not required i18n, 
it would be simple to skip those tests for mi subdirectory.
We just need to agree on a position concerning this matter.
I have no strong feelings in either direction, but it seems quite logical
that all messages that are only designated for front-end should rather not
be translated, as this would require even more work for the front-ends to
recognize them.

Pierre Muller
as ARI maintainer.