This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: MI error msgs and localization
On Wed, Feb 15, 2006 at 09:58:23AM +1300, Nick Roberts wrote:
> > I don't particular like to hard-code these strings. The list of messages I
> > gave previously are all marked as console-stream-output. What I am saying is
> > that localizing such error messages will hurt MI dependant tools since the
> > messages are highly useful for the front-end. I'm not sure what purpose
> > console-output really has in a Machine Interface as it tends to make sense
> > only to humans - but I guess some systems are making use of them.
> >
> > What I'd really like is to see them also wrapped in result-records (sample;
> > ignore syntax):
> >
> > ^failed,type="init-option-unrecognized",msg="Unrecognized option"
> >
> > Does that make any sense?
>
> We've already got ^error as a result field so it doesn't make any sense to me,
> and if "Unrecognized option" comes from the console stream then I think that
> can still change. The problem seems to be that of handling CLI error output
> in MI. I see that the standard GNU error function provides for an error
> number which is less likely to change:
>
> -- Function: void error (int STATUS, int ERRNUM, const char *FORMAT,
> ...)
>
> I wonder if GDB's error function could have one for MI e.g
>
> &"Unrecognized option\n"
> ^error,msg="Unrecognized option",code="35"
>
> or even
>
> &"Unrecognized option\n"
> ^error,code="35"
>
> instead of just:
>
> &"Unrecognized option\n"
> ^error,msg="Unrecognized option"
GCC developers spent a lot of time talking about this. I think the
trick to doing this right is actually to do it the way Bjarke
suggested: msg= as a free-form, explanatory text, and type= (or code=,
or something else) as a documented identifier. But using numbers for
the identifiers is not necessarily a good idea, because keeping track
of them is error-prone. I'd suggest that
type="init-option-unrecognized" was a lot more memorable than
"code=35".
We have to be careful what error messages get identifiers, though.
Please don't anybody go through the source indiscriminately adding
them. Many errors will still be subject to change even if you tack
permanent identifiers on them.
--
Daniel Jacobowitz
CodeSourcery