109177 - Get rid of strtok_r() clones ...

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Tracking, enhancement)

Description

[Roland Mainz]

Starting with the patch in bug 106372 we have a POSIX-conformant strtok_r()
function (|PL_strtok_r()|).

We should start killing the clones from the tree:
- |strtok()| - not threadsafe on all platforms (strtok_r()|PL_strtok_r() are
threadsafe)
- xpcom/ds/nsCRT.cpp version of strtok()
- strtok_r() itself - not available on all platforms (NSPR's PL_strtok_r() is
always available in Mozilla code)

Comment 1

[Ulrich Drepper]

See bug 81577, bug 81584, bug 99247, bug 81590 for some places.  If PL_strtok_r
is to be used the provided patches must of course be adjusted.

I personally don't like the idea of using a wrapper functions which isn't
necessary since this just adds (admitted little) bloat and eventually
significant performance penalties.  The implementation in the system library can
(and normally is) must more optimized.

Comment 2

[Roland Mainz]

> I personally don't like the idea of using a wrapper functions which isn't
> necessary since this just adds (admitted little) bloat and eventually
> significant performance penalties. 

I disagree in the case of the |strtok_r()|-clones used in Mozilla code. All the
clones listed above have disadvantages, mainly problems/issues which are
hard-to-debug... ;-(
 
> The implementation in the system library can (and normally is) must
> more optimized

Agreed, however this is not true for |PR_strtok_r| - I wrote is myself... :-)
A system function may be slightly "better" optimized or may be available as a
"buildin compiler function" - but strtok_r()&co. are not that often used (and 
AFAIK not in performance-critical code).

|PL_strok_r()| is far more portable than other functions listed here - and (with
the exception of the POSIX strtok_r()) has no disadvantages.

(BTW: I am going to file a bug in the not-so-far-future to get some #define
PL_function stdlib_equiv_function, e.g. |#define PL_strcpy(s1, s2) strcpy((s1),
(s2))| if the matching "native" function is available ...)

I would still "vote" to get rid of the clones: Less code, less problems, more
portable ... :-)

Comment 3

[Roland Mainz]

I'll take this one if noone else cares about this...
wtc ? cls ?

Comment 4

[Asa Dotzler [:asa]]

not mine. someone should take it.

Comment 5

[Asa Dotzler [:asa]]

Roland, you need to find  a better owner for this. I don't write code. 

Comment 6

[timeless]

.

Comment 7

[Hixie (not reading bugmail)]

Moving to NSPR -- this has nothing to do with Tabbed Browsing.

Comment 8

[BMO Automation]

Marking all tracking bugs which haven't been updated since 2014 as INCOMPLETE.
If this bug is still relevant, please reopen it and move it into a bugzilla component related to the work
being tracked. The Core: Tracking component will no longer be used.