Re: [PATCH] (x)memcoll: performance improvement when input is known to be NUL delimited.

[Chen Guo]

Hi Bruno,

    I'm going through and applying your suggestions, and I'm a bit iffy on this
one:
 
> > +/* Like memcoll, but S1 and S2 are known to be NUL delimited, thus no
> > +   modification to S1 or S2 are needed. */
> > +int
> > +memcoll_nul (char *s1, size_t s1len, char *s2, size_t s2len)
> > +{
> > +  int diff;
> 
> It would be good to start the function with a safety check:
> 
>      if (!(s1len > 0 && s1[s1len - 1] == '\0'))
>        abort ();
>      if (!(s2len > 0 && s2[s2len - 1] == '\0'))
>        abort ();

    If the whole point was performance, but we introduce 4 conditional
branches, that may more than cancel out any speedups we gain.

    For an extreme example, memcoll isn't threadsafe, but there isn't a
safety check of locking down the strings before writing a NUL byte to
the end.

    Could we just document it clearly that the (x)memcoll0 functions
absolutely require both S1 and S2 to be NUL delimited, and thus
leave it up to the user to know the usage?