On Wed, Oct 23, 2019 at 11:37:26AM -0500, Segher Boessenkool wrote: > On Wed, Oct 23, 2019 at 07:22:47PM +0300, Alexander Monakov wrote: > > On Wed, 23 Oct 2019, Eduard-Mihai Burtescu wrote: > > > @@ -384,6 +384,14 @@ rust_demangle_callback (const char *mangled, int > > > options, > > > return 0; > > > rdm.sym_len--; > > > > > > + /* Legacy Rust symbols also always end with a path segment > > > + that encodes a 16 hex digit hash, i.e. '17h[a-f0-9]{16}'. > > > + This early check, before any parse_ident calls, should > > > + quickly filter out most C++ symbols unrelated to Rust. */ > > > + if (!(rdm.sym_len > 19 > > > + && !strncmp (&rdm.sym[rdm.sym_len - 19], "17h", 3))) > > > > This can be further optimized by using memcmp in place of strncmp, since > > from > > the length check you know that you won't see the null terminator among the > > three > > chars you're checking. > > > > The compiler can expand memcmp(buf, "abc", 3) inline as two comparisons > > against > > a 16-bit immediate and an 8-bit immediate. It can't do the same for > > strncmp. > > The compiler does not currently do that, but it *could*. Or why not? The > compiler is always allowed to load 3 characters here, whether some string > has a NUL character earlier or not.
It is valid to call strncmp (mmap(...)+page_size-1, "abc", 3), the reading of the string should stop when 0 is seen. Of course, it might be that there is a strlen call visible and the strlen pass could figure out that rdm.sym_len contains the strlen, but maybe it isn't visible or there is some call in between that might in theory invalidate it. Jakub