Mysidia wrote:
>
> On Sun, 1 Apr 2001, Peter Ajamian wrote:
>
> > > There are very good reasons to _AVOID_ using strtok() which is really
> > > a very nasty function.
> >
> > No just avoid using it incorrectly such as how you try to use it in your
> > example.
>
> I ignored the results, so what? It's very clear that `p' is the only
> thing to hold the strtok(...) results in :P
You did worse than that, you tried to use it on a constant which will
prevent it from even compiling at all.
> The fact that code couldn't work (the values of strtok at the different
> call levels would clobber each other), is the very flaw I speak of.
I showed you one way it can work.
> You can't safely call _ANY_ function and then later use strtok with the
> first pointer NULL to iterate the thing you were last working with.. unless
> you know with 100% certainty that the function you are calling does not
> strtok and will never should strtok no matter how greatly someone
> bastardizes it.
This is true, so caution is necessary. Fact is you shouldn't use _any_
function without realizing the implications
> There are better devices than the ol' dangerous strtok...
Depends on your defenition of better, if you mean devices that are less
prone to break down under bad coding tecnique then you are correct, if
you mean devices which are more efficient then that is open to some
matter of debate.
> >From the NetBSD Programmer's Manual:
> BUGS
> There is no way to get tokens from multiple strings simultaneously.
This is a blanket statement which is simply untrue, a variation of the
tequnique I showed at the end of my prior post will easily allow strtok()
to be used for multiple simultaneous strings.
> >From the Linux programmer's manual:
Yep, I have this same man page on my own system. I've read it enough
times to know that first sententence is in there. You have to read past
it so see _why_ they say to "never use it".
> BUGS
> Never use this function.
This is a very limiting viewpoint if I _ever_ saw one.
> This function modifies its first
> argument. The identity of the delimiting character is
> lost.
That's right, it clobbers the input. If you want to preserve the input
just strcpy() or str_dup() it. Simple as that.
> This function cannot be used on constant string
This is exactly what your example tried to do. Again, strcpy() or
str_dup() the input if this is a problem.
> from SunOS' manual pages:
> Standard C Library Functions string(3C)
> [...]
> The strtok() function is Unsafe in multithreaded applica-
> tions. The strtok_r() function should be used instead.
> [...]
We're not dealing with a multithreaded app, if we were I would agree.
> > No strtok() is not reentrant in this fashion, of course, never once have
> > I come across a situation where I really wanted to use strtok() in such a
> > manner. Your example also shows that you really don't know the slightest
>
> The point isn't that you would want to use it in this matter; the point
> is, someone implementing a function dispatched from your little parser
> function might decide to strtok() without exactly realizing the
> consequences of their action or the side effects it would have on the
> parent function (probably causing them to attempt to use data that no
> longer exists -- unless you insanely use a global or static)
To dispatch such functions from inside the parser function would be
careless indeed.
> > thing about how strtok() works. The compilation would never get past the
> > first the strtok() line in your example and even if it does it will not
> > work anything like what you're expecting.
>
> No, it would compile fine; there are no syntax errors in it -- despite
> the fact that it's not meant to be compiled
How about warning: arg1 of strtok() implicitly castes out constantness
(or something like that)? Again, you're trying to pass a constant to a
function which does not allow constants to be passed as the first arg and
which will explicitly clobber that constant (thereby rendering it
somewhat less-than-constant).
> > No function will do what you want it to do if you use it incorrectly.
> To use the strtok function correctly it can't be called from within
> a child, this is a defect in the entire design of the thing.
It was designed to be fast and efficient. There is a usage price to pay
for that. Used correctly it can do what it was designed to do.
> > for (p1 = strtok(buf, " "), p2 = strtok(NULL, "");
> > p1; p1 = strtok(p2, " "), p2 = strtok(NULL, "")) {
> > printf("%s "strtok(p1, "-"));
> > }
> > }
> That's an iterative loop, not a recursion..
The example you gave is no more "recursive" than this. Anyways, it
demonstrates a wahy that strtok() can be used safely in recursion also.
> > Here is the output this little function would give...
> >
> > Th is a t
> I would expect that it would have an " est." in there somewhere as well..
The correct output is what I showed. Like I said, it's a rather
rediculous example. But the output is what is expected.
Regards, Peter
--
+---------------------------------------------------------------+
| FAQ: http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
| Archives: http://post.queensu.ca/listserv/wwwarch/circle.html |
+---------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/05/01 PST