This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/4] Improve generic strcspn performance



On 30-03-2016 15:00, 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"?
> 
> Wilco 
> 

My understanding is since GLIBC will not emit the __str{spn,cspn,brk}
anymore the symbols can now be build as compatibility mode only.
I will change it for this patch series and check out the ones you
noted.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]