James Carlson wrote:
> 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.
Aha, this is what tsdalloc() in strtok() is about.
The difference between strsep() and strtok() is also in that strsep()
modifies the pointer itself while strtok() does not (or I should say
cannot).
> 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
> [...]
Good catch, fixed. I found another instance which needs updating.
>> + 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?
I added the str{,c}spn sentences just to satisfy a comment in CR 6487100
which suggests to use these instead of strsep() in "internal code" (this
most probably means ON) and having strsep() only as a compatibility tool.
Given that string(3C) is a generic man page for just about everyone this
paragraph does not indeed have much sense. If we take that train of
thought further than the man page should have an example on how to use
strsep but for now let's leave it as it is. The example can be added
later on if needed.
Side blurb^Wnote: it seems to me that while this (or any other) man page
should inform the users about potential traps it should not serve as
fostering tool but instead offer the variety of APIs and let the
communities to do the rest.
New diff attached.
v.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: string_3C.diff
Type: text/x-patch
Size: 3404 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/on-discuss/attachments/20080731/05a89d76/attachment.bin>
