Andreas Ericsson wrote:
> Jakub Narebski wrote:
>> René Scharfe wrote:
>>> +#if !defined(__GLIBC__) && !__GLIBC_PREREQ(2, 1)
>>> +# define strchrnul(s, c) gitstrchrnul(s, c)
>>> +static inline char *gitstrchrnul(const char *s, int c)
>>> +{
>>> + while (*s && *s != c)
>>> + s++;
>>> +
>>> + return (char *)s;
>>> +}
>>> +#endif
>>> +
>>
>> This is good solution, although I'm not sure about the check itself.
>> What if somebody has libc which is not glibc, but it does have
>> strchrnul?
>
> They most likely fall into the minority that get to suffer from
> using code that's as fast as what's in there today, although
> a bit more readable. The glibc optimization is really only
> worthwhile for architectures where strchrnul()-like operations
> have microcode support, or when it's used on large strings.
If we end up using this solution, then adding test for strchrnul in the
configure (configure.ac and config.mak.in) is not needed...
> YMMV. I suppose rewriting it as
>
> #if defined(__GLIBC_PREREQ) && __GLIBC_PREREQ(2, 1)
#if !defined(HAVE_STRCHRNUL) && \
defined(__GLIBC_PREREQ) && __GLIBC_PREREQ(2, 1)
> # define HAVE_STRCHRNUL
> #endif
>
> #ifdef HAVE_STRCHRNUL
> ...
>
> would work too, and will provide an easier way out for other fellas
> wanting to say "Hey, my favourite solaris libc has this too!". OTOH,
> that rewrite can be done when the first such case appears.
...but if we end up using this version (be it HAVE_STRCHRNUL, or
NO_STRCHRNUL), then test for strchrnul in ./configure is I think
necessary.
--
Jakub Narebski
Poland
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
