Re: [PATCH] Do not transform strchr into rawmemchr

[Joseph Myers <joseph at codesourcery dot com>]

On Fri, 18 Nov 2016, Wilco Dijkstra wrote:

> Also I believe this remapping is needed for non-C90 functions that are used
> inside GLIBC itself. Eg. stpcpy is used a lot, and so is mapped to __stpcpy.
> Because __stpcpy is not a GCC builtin, it is mapped to __builtin_stpcpy.
> 
> Oddly enough all this happens in string/bits/string2.h, which is only included 
> for some optimization settings. If GLIBC is for example built for -Os it won't do
> this remapping, which means the namespace is polluted with non-C90 symbols.
> So should these internal remappings be moved to string.h and made conditional,
> so we only do this when building GLIBC?

(Bug 19463 is linknamespace failures with -Os and bug 15105 is localplt 
failures, but even if stpcpy appears in one or both sets of failures, 
there are a lot more as well, so fixing things for stpcpy might be 
relevant to such bugs but wouldn't fix them.)

Since the built-in expansions of stpcpy may not be expanded inline, we 
also have

libc_hidden_builtin_proto (stpcpy)

#if (!IS_IN (libc) || !defined SHARED) \
  && !defined NO_MEMPCPY_STPCPY_REDIRECT
/* Redirect calls to __builtin_mempcpy and __builtin_stpcpy to call
   __mempcpy and __stpcpy if not inlined.  */
extern __typeof (mempcpy) mempcpy __asm__ ("__mempcpy");
extern __typeof (stpcpy) stpcpy __asm__ ("__stpcpy");
#endif

in include/string.h - the first to cover the case of references to stpcpy 
inside shared libc, the rest to cover references elsewhere.

Thus, it should be possible just to call stpcpy directly everywhere in 
glibc rather than __stpcpy, and rely on those redirections to ensure that 
the calls actually end up being namespace-clean (but can be inlined if 
appropriate as GCC knows about stpcpy as a built-in function in gnu11 
mode).  Then the definition of __stpcpy in bits/string2.h should not be 
needed for building glibc.

-- 
Joseph S. Myers
joseph@codesourcery.com