Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #59191

Re: what the fork is wrong with strtok_r

Show key headers only | View raw

On 03/28/2015 08:39 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
> [...]
>> Note: if you're using gets() to read the text string, '\n' characters
>> will be replaced with '\0', which would make tokenizing on '\n' a little
>> difficult. If that fact is completely irrelevant to your problem, that
>> demonstrates the need for item 1.
> 
> If you're using gets(), that's your first problem.  gets() is inherently
> unsafe, and has been removed from the language as of the 2011 standard.
> 

YOu can just right that down as answer 48, which is wrong in this case,
but answer 48 should always be available when needed.

Just to be clear, I was using getline, just to see how hard it was.

BTW - it is also seemly insecure .

Then again Perl has

while(<>){
}


Now this is really begging for a rewrite:  They should try to get
12 year olds to read and understand these things.  strtok should
not be rocket science

       char *strtok_r(char *str, const char *delim, char **saveptr);

   Feature Test Macro Requirements for glibc (see feature_test_macros(7)):

       strtok_r(): _SVID_SOURCE || _BSD_SOURCE || _POSIX_C_SOURCE >= 1 ||
       _XOPEN_SOURCE || _POSIX_SOURCE

DESCRIPTION
       The strtok() function breaks a string into a sequence of zero  or
 more
       nonempty tokens.  On the first call to strtok() the string to be
parsed
       should be specified in str.  In each subsequent call that should
 parse
       the same string, str must be NULL.

       The  delim argument specifies a set of bytes that delimit the
tokens in
       the parsed string.  The caller may specify different strings  in
 delim
       in successive calls that parse the same string.

       Each  call  to  strtok()  returns a pointer to a null-terminated
string
       containing the next token.  This string does not include the
delimiting
       byte.  If no more tokens are found, strtok() returns NULL.
   A  sequence  of calls to strtok() that operate on the same string main‐
       tains a pointer that determines the point from which to start
searching
       for  the  next  token.  The first call to strtok() sets this
pointer to
       point to the first byte of the string.  The start of the next
token  is
       determined  by  scanning forward for the next nondelimiter byte
in str.
       If such a byte is found, it is taken as the start of  the  next
token.
       If  no  such byte is found, then there are no more tokens, and
strtok()
       returns NULL.  (A string that is empty or that contains only
delimiters
       will thus cause strtok() to return NULL on the first call.)

       The  end  of  each  token is found by scanning forward until
either the
       next delimiter byte is found or until the terminating null byte
('\0')
       is encountered.  If a delimiter byte is found, it is overwritten
with a
       null byte to terminate the current token, and strtok() saves a
pointer
       to  the following byte; that pointer will be used as the starting
point
       when searching for the next token.  In this case,  strtok()
returns  a
       pointer to the start of the found token.

       From  the  above description, it follows that a sequence of two
or more
       contiguous delimiter bytes in the parsed string is considered to
 be  a
       single  delimiter,  and that delimiter bytes at the start or end
of the
       string are ignored.  Put another way: the tokens returned  by
strtok()
       are  always  nonempty  strings.   Thus,  for  example, given the
string
       "aaa;;bbb,", successive calls to strtok() that  specify  the
delimiter
       string  ";,"  would return the strings "aaa" and "bbb", and then
a null
       pointer.

       The strtok_r() function is a reentrant version strtok().   The
saveptr
       argument  is  a pointer to a char * variable that is used
internally by
       strtok_r() in order to maintain context between successive  calls
 that
       parse the same string.

       On  the  first call to strtok_r(), str should point to the string
to be
       parsed, and the value of saveptr is ignored.  In subsequent
calls,  str
       should  be  NULL,  and  saveptr  should be unchanged since the
previous
       call.

       Different strings may be parsed concurrently using sequences  of
 calls
       to strtok_r() that specify different saveptr arguments.



NOW check out this insane example:
 Program source

       #include <stdio.h>
       #include <stdlib.h>
       #include <string.h>

       int
       main(int argc, char *argv[])
       {
           char *str1, *str2, *token, *subtoken;
           char *saveptr1, *saveptr2;
           int j;

           if (argc != 4) {
               fprintf(stderr, "Usage: %s string delim subdelim\n",
                       argv[0]);
               exit(EXIT_FAILURE);
           }

           for (j = 1, str1 = argv[1]; ; j++, str1 = NULL) {
               token = strtok_r(str1, argv[2], &saveptr1);
               if (token == NULL)
                   break;
               printf("%d: %s\n", j, token);

               for (str2 = token; ; str2 = NULL) {
                   subtoken = strtok_r(str2, argv[3], &saveptr2);
                   if (subtoken == NULL)
                       break;
                   printf(" --> %s\n", subtoken);
               }
           }

           exit(EXIT_SUCCESS);
       }



~~~~~~~~~~~~~~~~~~~~~~~~~~

What is NEEDED is a simple example...

Ruben






Ruben

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

what the fork is wrong with strtok_r what <ceo@iran.gov> - 2015-03-28 14:41 +0000
  Re: what the fork is wrong with strtok_r James Kuyper <jameskuyper@verizon.net> - 2015-03-28 10:57 -0400
    Re: what the fork is wrong with strtok_r Keith Thompson <kst-u@mib.org> - 2015-03-28 17:39 -0700
      Re: what the fork is wrong with strtok_r James Kuyper <jameskuyper@verizon.net> - 2015-03-28 21:33 -0400
      Re: what the fork is wrong with strtok_r ruben safir <ruben@mrbrklyn.com> - 2015-03-29 03:36 -0400
      Re: what the fork is wrong with strtok_r ruben safir <ruben@mrbrklyn.com> - 2015-03-29 03:39 -0400
  Re: what the fork is wrong with strtok_r Lőrinczy Zsigmond <nospam@for.me> - 2015-03-29 08:28 +0200

csiph-web