Hi Alejandro,
> > Oh wait. Should we have called the new function stpnul() instead of
> > strnul()?
> > Because it returns a pointer.
>
> ... We have other
> existing APIs that only have a variant that return an offset pointer,
> and their name is str*(), strchr(3) being the canonical example.
> stp*() would only be necessary where there's the two variants with the
> same name.
OK for keeping strnul then.
Among the str* functions that return a pointer (strchr, strrchr, strdup,
strpbrk, strstr), there is in particular strpbrk, which can be defined as
char *
strpbrk (const char *s, const char *char_set)
{
size_t n = strcspn (s, char_set);
return s[n] ? (char *) &s[n] : NULL;
}
So, as I understand it,
- stpcspn would be a variant of strpbrk,
- but stpspn is not such a variant.
* If we add only the stpspn function, we'll have tricky-to-remember
differences between stpspn and strpbrk.
* Whereas if we add both the stpspn and stpcspn functions, we'll have
two functions stpcspn, strpbrk that are merely variants of each other.
Neither of which is super desirable.
I'm thinking we should therefore leave the current asymmetric situation
(strspn, strcspn, strpbrk) alone. Especially since either case can also
be open-coded with a 'for' loop. And just 5 opportunities for stpspn()
in gnulib/lib/ — that does not seem worth the trouble (for users) of
learning and remembering this function.
Bruno