Re: [PATCH] Do not transform strchr into rawmemchr

[Zack Weinberg <zackw at panix dot com>]

On 11/17/2016 06:22 AM, Wilco Dijkstra wrote:
> Zack Weinberg wrote:
> 
>> I endorse the removal of the non-optimization, but ...
> 
>> ... wouldn't it be just as effective to remove this block entirely?
>> That is, don't #define strchr at all.
> 
> Well that's a good question. Most string functions directly use the GCC
> builtin either via a define or via an inline function, so I simply follow that
> convention. 
> 
> However is there any benefit in doing so? If there is no benefit then we could
> remove a lot of code from the GLIBC headers, particularly string.h (and your
> covariance patch could become even simpler without the inline functions).

Funny you should mention that; I'm right now working on a branch that
completely removes both bits/string.h and bits/string2.h -- not because
I want to actually do that (though I'm hoping we can do _most_ of it),
but because I think it will be handy to have around for experiments to
find out whether the existing string inlines are actually any use.

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.

cc: Joseph: do you know whether my understanding is accurate?

zw