Yes, what is potentially helpful is that you use STR_POS to provide the resulting string length for say, appendstr, where the string length has to be computed anyway because of the overall size restriction. However, this could have been done by providing an optional output parameter, e.g., a pointer to size_t. The caller can pass a null pointer if the resulting string length is not important, otherwise the function will write the resulting string length to the object pointed to by that pointer.Originally Posted by awsdert
I had searchstr in mind: you're incrementing both tok.i and tok.p at the same time when only one would have been needed. That said, it looks like you can avoid this by adding tokLen to tok.i, but doing it this way means that tok.i really is redundant since that index can be computed from the pointer. Furthermore, your while (*delim) loop looks strange: because of the strcspn call, you already know that tok.p must point to either a character equal to a delimiter, or to the null character.
This is not really about efficiency, but when I wrote one of my examples of strntok back in the other thread, I wrote a loop that looped backwards to avoid overwriting over an overlap. I find it strange that you would do this in appendstr. It isn't wrong, but just weird. Just use memcpy or strcpy (which can be used safely since the string lengths have been checked).
