Re: [PATCH] Do not transform strchr into rawmemchr

[Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>]

Joseph Myers wrote:
> On Thu, 17 Nov 2016, Zack Weinberg wrote:
> > Regarding __builtin_strfoo versus strfoo, I _think_ an inline forward to
> > __builtin_strfoo does something useful when either the name or the type
> > signature of 'strfoo' doesn't match what the compiler expects.  So, for
> > instance, we will want them in the covariance case as long as the C++
> > compiler hasn't had its builtins updated to know that there are now two
> > overloads of strwhatever -- but then they become unnecessary.  On the
> > other hand, in the strchr/rawmemchr case, the basic prototype for strchr
> > should be enough to clue the compiler that it knows what this function
> > does, with no further prompting.  I could be wrong about this.

> Mapping strfoo to __builtin_strfoo may also be useful in the case where 
> strfoo is not a C90 function (so the user may have used -std=c90 
> -D_GNU_SOURCE, getting the declaration of strfoo but without it being 
> built-in in the compiler).

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?

> In the strchr case, it's a C90 function so aside from inlines for C++ 
> overloads mapping to __builtin_strchr should not be of use (if someone 
> uses -fno-builtin or -ffreestanding there should be no expectation that 
> headers need to try to optimize things anyway, and even the case where 
> -std with feature test macros means the function is declared but not 
> built-in is pretty marginal).

I'll remove the strchr, strncpy, strcspn, strspn and strpbrk cases from string2.h then.

Wilco