[PATCH 1/4] Improve generic strcspn performance

[Richard Henderson]

On 03/30/2016 11:00 AM, Wilco Dijkstra wrote:
> 
> Richard Henderson wrote:
>> On 03/28/2016 08:19 AM, Adhemerval Zanella wrote:
>>> + /* The inline functions are not used from GLIBC 2.24 and forward, however
>>> +    they are required to provide the symbols through string-inlines.c
>>> +    (if inlining is not possible for compatibility reasons).  */
>>>  __STRING_INLINE size_t __strcspn_c1 (const char *__s, int __reject);
>>>  __STRING_INLINE size_t
>>>  __strcspn_c1 (const char *__s, int __reject)
>>
>> They could, however, be moved out of the installed header file and be given
>> compatibility symbol versions.
> 
> I have several patches out for review that move all the inlines from string2.h 
> to string/string-inlines.c for backwards compatibility and discontinue the complex
> inlining of some code from string2.h so one no longer needs to worry about
> accidental ABI changes.
> 
> See http://patchwork.sourceware.org/patch/10936/ for the strcspn move (this builds on
> http://patchwork.sourceware.org/patch/10933/ and http://patchwork.sourceware.org/patch/10934/).
> 
> What do you mean with "compatibility symbol versions"?

It means that the symbols are not available with a default version, and so new
programs cannot link against the symbol.  However, old programs that are
already linked will continue to use the old symbol version.

See e.g. nptl/pt-fork.c, wherein "fork" and "__fork" were removed from the
default symbols for libpthread, and so now are exported only as compatibility
symbols.


r~