illumos gate

Using strtok_r can be dangerous. There are steps that can be taken to use it securely and these should be followed by programmers and checked carefully by reviewers:
https://www.securecoding.cert.org/confluence/display/c/STR06-C.+Do+not+assume+that+strtok%28%29+leaves+the+parse+string+unchanged

Perhaps wcstok_s might be a better choice. It's also reentrant by design but includes bounds checks to avoid buffer overflows.

Alain O'Dea wrote:
...

Perhaps wcstok_s might be a better choice. It's also reentrant by design but includes bounds checks to avoid buffer overflows.

This is for in-kernel use only. The kernel uses only ASCII and therefore it doesn't make sense to deal with wide characters.

Yes, one has to know that strtok_r mutates the input string.

Good point!

Either way strtok/strtok_s may result in undesirable corner cases as it takes multiple adjacent delimiters as one. Are the cases of delimited parsing in the kernel that this is intended to clean up universally guaranteed to have non-empty fields? strtok isn't even capable of parsing /etc/passwd sensibly without client-code policing it heavily.

Maybe strchr or strcspn would be better for this. They are already available in-kernel as far as I can tell and don't suffer from the warts of strtok.

Please do not just import (or even write anew) an implementation of an 80s-style C library routine for string manipulation. We can surely do something better (easier to use, less error- and exploit-prone), even if it takes a while and requires some research or invention to come up with.