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

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

[GDB Administrator]

814a815,817
> 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:1512: code: sprintf: Do not use sprintf, instead use xstrprintf
gdb/mi/mi-main.c:1512:	  sprintf (p, ', read_result->data[i]);
> 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");

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

[Vladimir Prus]

GDB Administrator wrote:

> 814a815,817

>> 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]);

This warning is bogus in this context. How do I silence it?

>> 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,
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.

Comments?

- Volodya

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

[Pierre Muller]

> 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.
  

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

[Joel Brobecker]

> Of above warnings, only first appears to be added by a recent patch of mine,
> 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.

For error messages, ISTM that the intent would have to have the error
message displayed verbatim by the IDE, no? In that case, it would be
better if it was translated than not.  Otherwise, we place the burden
of providing translations on the IDE, which I think is a bad idea.

-- 
Joel

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

[André Pönitz]

On Monday 16 August 2010 16:45:26 ext Joel Brobecker wrote:
> > Of above warnings, only first appears to be added by a recent patch of mine,
> > 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.
> 
> For error messages, ISTM that the intent would have to have the error
> message displayed verbatim by the IDE, no? In that case, it would be
> better if it was translated than not.  Otherwise, we place the burden
> of providing translations on the IDE, which I think is a bad idea.

As someone working on a frontend for (among others) gdb I pretty 
much prefer a debugger creating non-translated messages as in my
case there are way more cases where an error message is not shown
to the user but rather triggers workarounds or other "invisible"
behaviour.

Also, in the rare cases where the error message are passed to the
user they are usually "enriched" by explaining them or by providing
additional context.

In either case the actual message is treated closer to something like
an "error id", not as a string ready for human consumption.

Maybe a solution would be to provide the translated message in
addition to a (preferably longterm unchanged) "error id" string?

Andre'