bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes

[Eli Zaretskii]

> From: Mattias Engdegård <mattiase@acm.org>
> Date: Sat, 24 Oct 2020 20:27:13 +0200
> Cc: 44173@debbugs.gnu.org
> 
> > I hoped/thought you intended to solve this issue as well, but if the
> > situation is no worse than it was before, it's fine to leave it at
> > that.  However, please retain at least part of the comment regarding
> > gdb-mi-decode-strings and the ambiguity related to its use, I think
> > it's important that people know that.
> 
> Yes, the valid parts of the comment will be kept.
> I'm not sure what a solution to the remaining problems would look like, but 
> it would probably involve splitting gdb-mi-decode-strings in separate 
> variables for file names and program values.

How do we know, at that level, whether a string is a file name or not?
And even if we succeed in knowing that about source file names of the
debuggee, we have no hope of knowing whether some string in the
debuggee is a file name or just a string.

> On the other hand, given that the world is converging to UTF-8, it may be a 
> disappearing problem?

The rate of the convergence is severely exaggerated.  And GDB can be
used to debug all kinds of targets, which is why it has settings for
the host and the target charsets.  As long as GDB doesn't convert
everything to UTF-8, I don't see how gdb-mi.el could do that.

> In any case, should we want to decode strings differently depending on their 
> structural position in the answer, I believe that it would be better done in 
> the field accessors instead of the parser. For example,
> 
>   (bindat-get-field breakpoint 'fullname)
> 
> might become something like
> 
>   (gdb-mi--get-string-field breakpoint 'fullname 'filename)
> 
> which would tell the accessor how to decode the field.

See above: this still doesn't solve the problem of knowing the correct
encoding, even in specific fields of specific responses.

> In the short term I suggest changing the default value of 
> gdb-mi-decode-strings to 't' as this gives the behaviour most commonly 
> expected by the user. However, it is not critical, and in any case orthogonal 
> to the issue at hand. What do you think?

I'm not at all sure this is what users want, since non-ASCII file
names in debugging are quite rare.  But I don't mind changing the
default value.

> >> +       (t
> >> +        (error "Unrecognised escape char: %c" (following-char))))
> > 
> > How about leaving the text unchanged instead of signaling an error
> > (and thus preventing the entire data from getting to the higher
> > levels)?
> 
> Maybe, but I really dislike hiding bugs by being overly tolerant.

We could display a warning.  But interrupting (and possibly ruining) a
debugging session because of our bug is very harsh: the user is
certainly not guilty.