[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: rawmemchr usage
From: |
Bruno Haible |
Subject: |
Re: rawmemchr usage |
Date: |
Wed, 27 May 2009 00:56:35 +0200 |
User-agent: |
KMail/1.9.9 |
Eric Blake wrote:
> + strtok_r: use rawmemchr for speed.
> + * lib/strtok_r.c (__rawmemchr): Use faster rawmemchr.
> + * modules/strtok_r (Depends-on): Add rawmemchr.
> ...
> Likewise, what about these other modules that only use strchr to find the
> terminating byte of a known-terminated string, where rawmemchr could be the
> faster choice?
>
> lib/argz.c: entry = strchr (entry, '\0') + 1;
> lib/argz.in.h: __entry = strchr (__entry, '\0') + 1;
> lib/canonicalize-lgpl.c: dest = strchr (rpath, '\0');
> lib/canonicalize.c: dest = strchr (rname, '\0');
> lib/glob.c: end_name = strchr (unescape, '\0');
This time I'm with Sam Steingold's argumentation: We should avoid creeping
additions of dependencies. rawmemchr is additional code to be compiled on
all non-glibc platforms, whereas strchr() is present in libc on all systems.
There is nothing wrong with the use of strchr(). I even doubt whether the
code in lib/rawmemchr.c can beat assembly language code like the one glibc
has for strchr. Furthermore, the code in lib/canonicalize*.c is certainly
not speed relevant (since it mostly makes system calls).
Bruno
- rawmemchr usage, Eric Blake, 2009/05/26
- Re: rawmemchr usage,
Bruno Haible <=