public inbox for gdb-cvs@sourceware.org help / color / mirror / Atom feed
From: Pedro Alves <palves@sourceware.org> To: gdb-cvs@sourceware.org Subject: [binutils-gdb] Clarify why we unit test matching symbol names with 0xff characters Date: Tue, 31 May 2022 12:57:06 +0000 (GMT) [thread overview] Message-ID: <20220531125706.528033836655@sourceware.org> (raw) https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=102a644eaaa8b258f021da71028c32e0744d73ce commit 102a644eaaa8b258f021da71028c32e0744d73ce Author: Pedro Alves <pedro@palves.net> Date: Tue May 31 13:36:32 2022 +0100 Clarify why we unit test matching symbol names with 0xff characters In the name matching unit tests in gdb/dwarf2/read.c, explain better why we test symbols with \377 / 0xff characters (Latin1 'ÿ'). Change-Id: I517f13adfff2e4d3cd783fec1d744e2b26e18b8e Diff: --- gdb/dwarf2/read.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index c4578c687d2..848fd5627b8 100644 --- a/gdb/dwarf2/read.c +++ b/gdb/dwarf2/read.c @@ -3628,10 +3628,17 @@ static const char *test_symbols[] = { is "function" in PT). */ u8"u8função", - /* \377 (0xff) is Latin1 'ÿ'. */ + /* Test a symbol name that ends with a 0xff character, which is a + valid character in non-UTF-8 source character sets (e.g. Latin1 + 'ÿ'), and we can't rule out compilers allowing it in identifiers. + We test this because the completion algorithm finds the upper + bound of symbols by looking for the insertion point of + "func"-with-last-character-incremented, i.e. "fund", and adding 1 + to 0xff should wraparound and carry to the previous character. + See comments in make_sort_after_prefix_name. */ "yfunc\377", - /* \377 (0xff) is Latin1 'ÿ'. */ + /* Some more symbols with \377 (0xff). See above. */ "\377", "\377\377123", @@ -3701,7 +3708,8 @@ test_mapped_index_find_name_component_bounds () } /* Check that the increment-last-char in the name matching algorithm - for completion doesn't get confused with Ansi1 'ÿ' / 0xff. */ + for completion doesn't get confused with Ansi1 'ÿ' / 0xff. See + make_sort_after_prefix_name. */ { static const char *expected_syms1[] = { "\377", @@ -3770,7 +3778,8 @@ test_dw2_expand_symtabs_matching_symbol () } /* Check that the name matching algorithm for completion doesn't get - confused with Latin1 'ÿ' / 0xff. */ + confused with Latin1 'ÿ' / 0xff. See + make_sort_after_prefix_name. */ { static const char str[] = "\377"; CHECK_MATCH (str, symbol_name_match_type::FULL, true,
reply other threads:[~2022-05-31 12:57 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20220531125706.528033836655@sourceware.org \ --to=palves@sourceware.org \ --cc=gdb-cvs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).