home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / std / c / 3033 < prev    next >
Encoding:
Text File  |  1992-11-18  |  1.8 KB  |  59 lines
  1. Newsgroups: comp.std.c
  2. From: jes@grendel.demon.co.uk (Jim Segrave)
  3. Path: sparky!uunet!pipex!demon!grendel.demon.co.uk!jes
  4. ReplyTo: jes@grendel.demon.co.uk
  5. Subject: idle query on strtok()
  6. Distribution: world
  7. X-Mailer: cppnews $Revision: 1.19 $
  8. Organization: None
  9. Lines: 21
  10. Date: Tue, 17 Nov 1992 22:19:53 +0000
  11. Message-ID: <722063993snx@grendel.demon.co.uk>
  12. Sender: usenet@gate.demon.co.uk
  13.  
  14.  
  15. Is strtok()'s behaviour defined for tokens already taken from a string?
  16.  
  17. For example, suppose I have:
  18.     char zoe[] = "aaa bbb";
  19.     char *first, *second;
  20. If I do:
  21.     first = strtok (zoe, " "); 
  22.     second = strtok (NULL, " ");
  23.     printf ("%s\n%s\n", first, second);
  24. I expect the output:
  25.     aaa
  26.     bbb
  27.  
  28. First idle query:
  29.  
  30. Can I *portably* change the contents of a token returned by strtok
  31. without affecting the behaviour of subsequent calls?
  32. If I do:
  33.     first = strtok (zoe, " "); 
  34.     printf ("%s\n", first);
  35.     strcpy (first, "!!!");        /* corrupt the first bit */
  36.     second = strtok (NULL, " ");
  37.     printf ("%s\n", second);
  38.  
  39. Do I have a guarantee that I'll get the same output?
  40. What if I change the 'corrupt ...' line to
  41.     memset (first, 0, strlen (first) + 1);
  42.  
  43. Second idle query:
  44.  
  45. Does strtok() promise that the tokens delivered will be untouched
  46. by subsequent calls to strtok()? Could a conforming implementation
  47. keep the original pointer to the string to be tokenised and use the
  48. string itself to retain state (say by filling from the start of the string
  49. through to the last token delivered with some absurd character)?
  50.  
  51. I've never met an implementation which did care about previously
  52. delivered tokens or which went back and wantonly trashed them, but I've
  53. never seen any documentation which says that a perverse implementor
  54. couldn't choose to do this.
  55.  
  56. --
  57. Jim Segrave (Segrave Software Services)     jes@grendel.demon.co.uk
  58.  
  59.