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)

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.

> 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 ... :-)

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

not mine. someone should take it.

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

.

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

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.