This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/4] Improve generic strcspn performance
- From: Richard Henderson <rth at twiddle dot net>
- To: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Cc: nd <nd at arm dot com>
- Date: Wed, 30 Mar 2016 11:46:05 -0700
- Subject: Re: [PATCH 1/4] Improve generic strcspn performance
- Authentication-results: sourceware.org; auth=none
- References: <1459178389-14133-1-git-send-email-adhemerval dot zanella at linaro dot org> <1459178389-14133-2-git-send-email-adhemerval dot zanella at linaro dot org> <56FC113B dot 7010003 at twiddle dot net> <DB3PR08MB008942E80487CA77DB82EE0D83980 at DB3PR08MB0089 dot eurprd08 dot prod dot outlook dot com>
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~