[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes
From: |
Mattias Engdegård |
Subject: |
bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes |
Date: |
Fri, 23 Oct 2020 16:21:55 +0200 |
23 okt. 2020 kl. 15.19 skrev Eli Zaretskii <eliz@gnu.org>:
> The basic ambiguity, AFAIR, is what is described last here: a string
> reported bu GDB could include literal \nnn sequences, which are not
> non-ASCII characters that GDB/MI converts to octal escapes. The
> information which was which is lost once we receive the GDB/MI output.
So you mean that GDB would produce the value "\303" that does not stand for a
string containing the single byte octal 303? When does this occur?
> AFAIU, this bug's root cause is the way we solved the ambiguity, which
> basically assumes one of the possible interpretations should be
> preferred to another, because it is more popular/useful.
Then we disagree. The code doesn't do the right thing if gdb-mi-decode-string
is nil, unless you by 'ambiguity' mean that GDB sometimes inserts a spurious
backslash that should be ignored. When gdb-mi-decode-string is non-nil, it is
sometimes wrong as well.
> Let me turn the table and ask you how did you get that string you show
> in the original report?
A program in the C language containing the local declaration
char *s = "\303\266";
produces nonsense in the 'Locals' window when debugged. It doesn't matter what
the string means; I would have been happy with gdb/emacs interpreting it as
utf-8, latin-1 or just raw bytes presented in octal or hex.
> And what will then happen to non-ASCII strings and file names reported
> by GDB? How will our parser solve that?
The parser can either leave the strings as undecoded unibyte strings -- that
is, "\303\266" would be a 2-char string -- or decode them according to
gdb-mi-decode-strings, in which case it might become a 1-char multibyte string.
In the former case, the code receiving the parse tree could decide what to do
with the strings and how to display them, perhaps on a case-by-case basis.
> Do you intend to extend the existing parser or write a new one from
> scratch?
Extending the existing one appears sensible, just replacing the JSON tour.
- bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes, Mattias Engdegård, 2020/10/23
- bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes, Eli Zaretskii, 2020/10/23
- bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes, Mattias Engdegård, 2020/10/23
- bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes, Eli Zaretskii, 2020/10/23
- bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes,
Mattias Engdegård <=
- bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes, Eli Zaretskii, 2020/10/23
- bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes, Mattias Engdegård, 2020/10/23
- bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes, Eli Zaretskii, 2020/10/23
- bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes, Mattias Engdegård, 2020/10/24
- bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes, Eli Zaretskii, 2020/10/24
- bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes, Mattias Engdegård, 2020/10/24
- bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes, Eli Zaretskii, 2020/10/24
- bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes, Mattias Engdegård, 2020/10/24
- bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes, Mattias Engdegård, 2020/10/27
- bug#44173: 28.0.50; gdb-mi mangles strings with octal escapes, Eli Zaretskii, 2020/10/31