Vladimir Kotal writes:
> PSARC case for strsep() [1] still lacks a man page diff. Since strsep()
> shares some deficiencies with strtok() and we have functions that do not
> have any of those problems in libc (str[c]spn()) strsep() should be used
> merely as a compatibility tool (see CR 6487100). I tried to get that
> message into the man page.
I think aliasing strsep and strtok together as "bad things" might not
be a good idea. While they both modify the original string (which is
often distasteful as a matter of design), only strtok uses static (per
thread) data.
That makes a big difference. You can't (for instance) parse two
different strings at the same time using strtok. This unfortunately
*does* occur in practice (as with breaking a string into fields, each
of which contains subfields using a different delimiter).
strsep is roughly equivalent to strtok_r, which is "recommended" as a
replacement for strtok.
You'll probably want to update this text to mention strsep:
Do not pass the address of a character string literal as the
argument s1 to either strtok() or strtok_r(). These func-
tions can modify the storage pointed to by s1. The C99 stan-
dard specifies that attempting to modify the storage occu-
pied by a string literal results in undefined behavior. This
[...]
> + However, both strtok() and strsep() modify the original string.
> + strspn() or strcspn() should be used instead.
This comment seems odd, given the text elsewhere in this page:
The strtok() function is safe to use in multithreaded appli-
cations because it saves its internal state in a thread-
specific data area. However, its use is discouraged, even
for single-threaded applications. The strtok_r() function
should be used instead.
I'm not sure I'd recommend strspn/strcspn specifically. Aren't there
other tools available?
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
