[Bug-gnulib] Re: strtok_r

[Simon Josefsson]

Oops, I didn't see your mail, I'll wait to commit until everything has
been sorted out.  Later: it seems no changes were required, so I'm
installing it.

Paul Eggert <address@hidden> writes:

> Simon Josefsson <address@hidden> writes:
>
>> * Is strchr the same as rawmemchr?
>
> No, strchr (BUF, CH) stops when it finds either CH or a null byte.
> rawmemchr (BUF, CH) stops only when it finds CH.
>
> If CH is zero (which is the case here), the two functions are
> equivalent, but presumably rawmemchr is faster.

So using strchr should work fine here, right?

I suspect strchr is written in assembler anyway, so using strchr might
be faster on sane systems.

>> I didn't like rawmemchr.
>
> Just as an aside, I didn't even know about rawmemchr until now.  But
> it looks nice to me.  What don't you like about it?

Using strchr feels safer than adding 190 lines of code, especially
code that is so complicated that half of it is comments.  And it is
not clear what assumptions the code make, either.  Will it work with
128 bit unsigned long's, for example?

>> * Glibc doesn't seem to have restrict keywords in the *.c file.  Is
>>   that a bug?  Is it sufficient to have them in *.h?
>
> C99 isn't entirely clear on the subject.  I think the intent was that
> it's sufficient to have them in *.h.  I wouldn't worry about it unless
> we run across a (possibly pre-C99) compiler that complains about it,
> or unless it turns into a real performance problem.

OK.

Thanks.