Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!usc!bloom-beacon!adam.pika.mit.edu!scs
From: scs@adam.pika.mit.edu (Steve Summit)
Newsgroups: comp.lang.c
Subject: strtok (was: In defense of scanf)
Message-ID: <12381@bloom-beacon.MIT.EDU>
Date: 2 Jul 89 16:24:52 GMT
References: <225800176@uxe.cso.uiuc.edu> <11831@bloom-beacon.MIT.EDU> <824@cbnewsl.ATT.COM>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Lines: 21

In article <824@cbnewsl.ATT.COM>, mpl@cbnewsl.ATT.COM (michael.p.lindner) (I think) writes:
> Hope you never have to do anything complex.  If you call strtok on e string
> in the middle of a strtok of another string it trashes its state information
> on the first string (a little known feature), which can cause extremely
> elusive bugs.

This shouldn't be a "little known feature;" it is obvious from
the man page that strtok must keep private state, and the first
thing any good programmer should worry about when "private state"
is mentioned is "non-reentrancy" or "non-concurrency."

strtok is a horrid routine, precisely because of this aspect; I
can't believe SYSIII or SYSV (or wherever it originated) adopted
it, and then of course X3J11 had to go and further legitimize it.
(The rest of the "new" str* functions -- strspn, strpbrk, etc. --
aren't much better.  Can you say orthogonal?  "Orthghnpgtphl!"
Hmm, not very good.  The (r)index to str(r)chr change still
rankles, too.)

                                            Steve Summit
                                            scs@adam.pika.mit.edu