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

[Mattias Engdegård]

24 okt. 2020 kl. 20.44 skrev Eli Zaretskii <eliz@gnu.org>:

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

I think we can distinguish source file names by what field they occur in (which 
is why I thought that doing it in the accessor might do), but you are certainly 
right about strings in the program being debugged.

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

I don't disagree. What we can do is to have defaults that cover the most likely 
case and let users with less common setups change those.

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

That's true, and I don't have a good answer. Perhaps we somehow can get GDB (or 
the OS, if it is the file system) to inform us. But as you noted, even GDB 
doesn't know what encoding the debugged program uses. It could very well be 
multiple encodings at once.

A serious debugger interface would probably push this decision to the data 
presentation layer and allow the user to specify how he wants to view the 
contents of a particular string, in the same way that users select radix for 
viewing integers. Not sure how this would be done in gdb-mi.

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

Let's do this separately then. It seems unlikely to cause trouble.

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

I definitely have some sympathy for that point of view, but then again, 
warnings that don't impede the user's progress tend to go unfixed, so being 
'nice' to the user isn't necessarily in his or her best interest.

But we could try (warn ...), which I suppose you were thinking about? It's 
fairly visible.