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] intl: Merge with gettext version 0.19.3


On 11 December 2014 at 14:19, Joseph Myers <joseph@codesourcery.com> wrote:
> On Wed, 10 Dec 2014, Will Newton wrote:
>
>> The merge has dropped many uses of __glibc_likely/unlikely. This is
>> intentional given that it eases merging. It seems to me that the cost
>> of continually rewriting these lines when merging and the risk of adding
>> bugs when doing so outweighs the benefits of using these macros when
>> code is shared with another project.
>
> It also appears to revert the use of __rawmemchr instead of strchr in
> explodename.c (which, unlike __glibc_likely/unlikely, would make the
> generated code less efficient) - is that deliberate?  Could you list
> exactly which glibc-local changes are reverted in this merge without being
> replaced by something equivalent?

Using __rawmemchr seemed an unnecessary micro-optimization. strchr has
the advantages:

1. It's standard
2. The compiler may well optimize it to strlen with a zero second argument
3. More architectures implement a fast version of strchr/strlen than rawmemchr

That said performance is highly unlikely to be an issue here. From
that point of view it seemed a wiser choice to switch glibc to use
strchr than spend time trying to persuade gettext upstream to use
rawmemchr.

The patch intends to not revert any glibc local changes but where it
does they should be listed in the changelog, otherwise it is likely an
error.

-- 
Will Newton
Toolchain Working Group, Linaro


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