public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rene Scharfe <l.s.r@web.de>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] strtok -> strsep (The Easy Cases)
Date: Fri, 4 May 2001 13:07:56 +0200	[thread overview]
Message-ID: <01050413055100.00907@golmepha> (raw)
In-Reply-To: <m14vTua-001QLyC@mozart>
In-Reply-To: <m14vTua-001QLyC@mozart>

Am Freitag,  4. Mai 2001 02:57 schrieb Rusty Russell:
> In message <01050120580701.01713@golmepha> you write:
> > Hello,

Hi!

> >
> > the patch at the bottom does the bulk job of strtok replacement. It's a
> > very boring patch, containing easy cases, only. It became a bit big, too,
> > but I trust you can digest it nevertheless. It's made against kernel
> > version 2.4.4.
>
> There are two cases where the substitution is problematic:

Yes, but...

The cases which my patch modifies are of a different kind:

	int parse_options(char *options)
	{
		char *p;

		/* for (p = strtok(options, ","); p; p = strtok(NULL, ",")) { */
		while (p = strsep(&options, ",")) {
			/* ... */
		}
		return 0;
	}

No temporary array, no kfree(). Our variable "options" is used for strtsep,
only. Notice btw. how we destoy the string content to which "options"
points with both strtok and strsep.

That said, it's possible I made a stupid mistake, of course. Or two. Do
you agree on the correctness of the code above? If not, forget the whole
thing and I'll try again later.


>
> Array:
> 	char tmparray[500];
> 	strcpy(tmparray, str);
>
> 	/* for (p = strtok(tmparray, "n"); p; p = strtok(NULL, "n")) { */
> 	while ((p = strsep(&tmparray, ","))) {
>
> This is clearly wrong, and invokes a compiler warning.  &tmparray ==
> tmparray (a cute C oddity I've never really liked).  You are blowing
> away the first few characters in tmparray, and your parser won't work
> properly.
>
> Dynamic:
>
> 	char *tmp = strdup(str);
>
> 	/* for (p = strtok(tmp, "n"); p; p = strtok(NULL, "n")) { */
> 	while ((p = strsep(&tmp, ","))) {
> 	...
> 	}
>
> 	kfree(tmp);
>
> Here, tmp has changed in the strsep implementation, and kfree will do
> bad things.
>
> There is a real reason to avoid strtok, and that is SMP and multple
> threads calling it at once (that said, I don't know of a problem yet).
> But this patch is a step backwards.
>
> Rusty.
> --
> Premature optmztion is rt of all evl. --DK


René


  reply	other threads:[~2001-05-04 11:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-01 18:58 [PATCH] strtok -> strsep (The Easy Cases) Rene Scharfe
2001-05-04  0:57 ` Rusty Russell
2001-05-04 11:07   ` Rene Scharfe [this message]
2001-05-04 14:30     ` Rusty Russell
  -- strict thread matches above, loose matches on Subject: below --
2001-05-04 21:17  René Scharfe 

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=01050413055100.00907@golmepha \
    --to=l.s.r@web.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox