Bruno Haible <[email protected]> writes: > 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).
I also prefer using strchr rather than rawmemchr here. It is simpler to understand. /Simon
