Re: [PATCH 1/2] Add strchrnul()
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Nov 9, 2007, 16:44 UTC
- Message-ID
- <200711091744.50017.jnareb@gmail.com>
- In-Reply-To
- <473467C4.8020208@op5.se>
Andreas Ericsson wrote:
> Jakub Narebski wrote: >> René Scharfe wrote:
Show 21 quoted lines
>>> +#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)Show 9 quoted lines
> # 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