Re: [PATCH] Refactor rust-demangle to be independent of C++ demangling.

[Jakub Jelinek <jakub@redhat.com>]

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