strtok and strtok_r

[siddhu]

Dear experts,

As I know strtok_r is re-entrant version of strtok.
strtok_r() is called with s1(lets say) as its first parameter.
Remaining tokens from s1 are obtained by calling strtok_r() with a
null pointer for the first parameter.
My confusion is that this behavior is same as strtok. So I assume
strtok_r must also be using any function static variable to keep the
information about s1. If this is the case then how strtok_r is re-
entrant?
Otherwise how it keeps the information about s1?

Regards,
Siddharth

[Charlie Gordon]

"Richard Heathfield" <rj*@see.sig.in valida écrit dans le message de news:
tJ************* *************** **@bt.com...

Charlie Gordon said:

>"Richard Heathfield" <rj*@see.sig.in valida écrit dans le message de
news: Ma************* ********@bt.com...

>>Charlie Gordon said:

"CBFalcone r" <cb********@yah oo.coma écrit dans le message de news:
46************* **@yahoo.com...

<snip>

I have no idea what
strtok_r is, except that it invades user namespace.

You must be joking Mr Falconer.

No, he's toeing the group line, such as it is. As far as comp.lang.c
is concerned, there is *no such function* as strtok_r. If this
question were to arise in, say, comp.unix.progr ammer, Chuck's answer
might be very different.

If he would give a different answer on a different group, one of these
statements would be a lie or a joke.

...or a way of making a point, a la "Ich bin ein Berliner", with which
John F Kennedy bolstered the morale of West Berlin's citizens in June
1963. It was not "true" in the literal sense, but neither was it a lie
or a joke.

Except CBFalconer is no John F. Kennedy ;-)
His blunt rethoric does not bolster any one's morale, sarcasm does no good.

>So he is a fundamentalist, ostracist, extremist...

If you feel forced to resort to personal attacks, I can only assume you
have no logical arguments to put forward.

You are right, I should not have attributed to malice that which can be
adequately explained by plain ignorance. But I repeat: to not use strtok
anymore, check for availability of strtok_r or implement it locally from the
public domain source that has been posted above.

--
Chqrlie.

[Francine.Neary]

On Sep 15, 1:40 pm, "Joachim Schmitz" <nospam.j...@sc hmitz-digital.de>
wrote:

It s is NULL, this version only returns NULL if the implemenation's
malloc(0) returns NULL too

Entirely consistent with the standard library string functions - if
you pass them a char * that doesn't point to a string, the behavior is
undefined.

<OT>
And this is one case where "the thing you hope will happen" probably
doesn't - e.g. trying to compute strlen(NULL) on a GNU system produces
a seg fault).
</OT>

>
Bye, Jojo

[Charlie Gordon]

"Joachim Schmitz" <no*********@sc hmitz-digital.dea écrit dans le message
de news: fc**********@on line.de...

"Joachim Schmitz" <no*********@sc hmitz-digital.deschri eb im Newsbeitrag
news:fc******** **@online.de...

>>
<Fr*********** *@googlemail.co mschrieb im Newsbeitrag
news:11******* *************** @g4g2000hsf.goo glegroups.com.. .
<snip>
My suggestion would be:

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

char *my_strdup(cons t char *s)
{
size_t len;
char *t;
if(t=malloc(len =strlen(s)+1))
memcpy(t, s, len);
return t;
}

It s is NULL, this version only returns NULL if the implementation' s
malloc(0) returns NULL too

oops, sorry somehow my quoting was wrong.

Only the last sentence was mine...

And it does not make much sense ;-)
If s in NULL, strlen(s) invokes undefined behaviour.
otherwise, len is always0, and the code does not depend on the behaviour
of malloc(0)

--
Chqrlie.

[Joachim Schmitz]

<Fr************ @googlemail.com schrieb im Newsbeitrag
news:11******** *************@n 39g2000hsh.goog legroups.com...

On Sep 15, 1:40 pm, "Joachim Schmitz" <nospam.j...@sc hmitz-digital.de>
wrote:

>It s is NULL, this version only returns NULL if the implemenation's
malloc(0) returns NULL too

Entirely consistent with the standard library string functions - if
you pass them a char * that doesn't point to a string, the behavior is
undefined.

Fair enough, but I'd prefer my own functions to do better than that, so I
like Charlie Gordon's implementation better.

<OT>
And this is one case where "the thing you hope will happen" probably
doesn't - e.g. trying to compute strlen(NULL) on a GNU system produces
a seg fault).
</OT>

Damn, here too...
anwyway: see above

Bye, Jojo

[Charlie Gordon]

<Fr************ @googlemail.com a écrit dans le message de news:
11************* ********@g4g200 0h...legrou ps.com...

On Sep 15, 2:02 pm, "Charlie Gordon" <n...@chqrlie.o rgwrote:

><Francine.Ne.. [e-mail] ma écrit dans le message de news:
1189858659.251 030.194...@g4g2 000hsf.googlegr oups.com...

>>My suggestion would be:

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

>>char *my_strdup(cons t char *s)
{
size_t len;
char *t;
if(t=malloc(len =strlen(s)+1))
memcpy(t, s, len);
return t;
}

You code performs the task, but I find it misleading to call len a var
iable that is not the length of the string. I prefer to use size for
this purpose.

Furthermore, this code would not pass my default warning settings.
Assignment as an test expression is considered sloppy and error prone.

Tell that to Kernighan and Ritchie. :)

They might read this thread, I am sure they would care to comment.

Coding conventions is a very effective tool to catch bugs at an early
stage in development. Using all the help the compiler and other
automated tools can give at tracking potential errors disguised as
suspicious use of certain operators enhances productivity.

There is no gain at writing

size_t len;
char *t;
if(t=malloc(len =strlen(s)+1)) ...

instead of

size_t size = strlen(s) + 1;
char *t = malloc(size);
if (t) ...

The latter is much more readable and less error prone.

Your version did improve on mine by using memcpy to copy the '\0'
instead of writing separate code for that.

--
Chqrlie.

Is there a reason for the typo in your signature?

chqrlie is my handle, is there a reason you don't sign your messages ?

[Joachim Schmitz]

"Charlie Gordon" <ne**@chqrlie.o rgschrieb im Newsbeitrag
news:46******** *************** @news.free.fr.. .

<Fr************ @googlemail.com a écrit dans le message de news:
11************* ********@g4g200 0h...legrou ps.com...

>On Sep 15, 2:02 pm, "Charlie Gordon" <n...@chqrlie.o rgwrote:

>><Francine.Ne. ..@googlemail.c oma écrit dans le message de news:
1189858659.25 1030.194...@g4g 2000hsf.googleg roups.com...
My suggestion would be:

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

char *my_strdup(cons t char *s)
{
size_t len;
char *t;
if(t=malloc(len =strlen(s)+1))
memcpy(t, s, len);
return t;
}

You code performs the task, but I find it misleading to call len a var
iable that is not the length of the string. I prefer to use size for
this purpose.

Furthermore , this code would not pass my default warning settings.
Assignment as an test expression is considered sloppy and error prone.

Tell that to Kernighan and Ritchie. :)

They might read this thread, I am sure they would care to comment.

Coding conventions is a very effective tool to catch bugs at an early
stage in development. Using all the help the compiler and other
automated tools can give at tracking potential errors disguised as
suspicious use of certain operators enhances productivity.

There is no gain at writing

size_t len;
char *t;
if(t=malloc(len =strlen(s)+1)) ...

instead of

size_t size = strlen(s) + 1;
char *t = malloc(size);
if (t) ...

The latter is much more readable and less error prone.

Your version did improve on mine by using memcpy to copy the '\0'
instead of writing separate code for that.

True but quite easy to fix:
char *my_strdup(cons t char *str) {
char *dest = NULL;

if (str) {
size_t size = strlen(str) + 1;
dest = malloc(size);
if (dest)
memcpy(dest, str, size);
}
return dest;
}

[CBFalconer]

Charlie Gordon wrote:

"CBFalconer " <cb********@yah oo.coma écrit:

.... snip about tknsplit and strtok ...

>

>Which, IMO, is a major improvement. It also detects missing
tokens. It (once more) is NOT strtok. I have no idea what
strtok_r is, except that it invades user namespace.

You must be joking Mr Falconer. You probably never heard of
Unix, or even Linux... Or do you live on this remote planet
Microsoft has not settled yet ? If you have no idea what
strtok_r is, learn something new today:
http://linux.die.net/man/3/strtok_r
or if you like Microsoft's version better (part of the secure
string proposal)
http://msdn2.microsoft.com/en-us/lib...z3(VS.80).aspx

This newsgroup is comp.lang.c. C is defined by the various C
standards, present or past, and includes K&R for times previous to
1989. None of these define, or even mention, strtok_r. Thus,
without standard C code, published in the same message, discussion
of it is off-topic here. The name is still reserved for the
implementor. As I said, it doesn't exist. Unix, Linux, Microsoft
have no influence whatsoever.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Richard Heathfield wrote:

CBFalconer said:

<snip>

>I have no idea what strtok_r is, except that it invades user
namespace.

No, it doesn't.

Well, it's not exactly a typo, but ....

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[CBFalconer]

Charlie Gordon wrote:

"pete" <pf*****@mindsp ring.coma écrit:

.... snip ...

>>
Intsead of using realloc in a loop, I think most programmers
would write strdup with one function call to strlen and one to
malloc and one to strcpy.

Or more efficiently calling memcpy instead of strcpy.

char *strdup(const char *str) {
size_t len;
char *dest = NULL;

if (str) {
len = strlen(str);
dest = malloc(len + 1);
if (dest) {
memcpy(dest, str, len);
dest[len] = '\0';
}
}
return dest;
}

I challenge the 'more efficient'. It will be highly dependent on
the compiler, but at the simplest you would be trading the effort
of an extra procedure call against the possible efficiency
improvement. Since most strings are short (in my case, probably
under 10 or 20 chars) this 'improvement' is a chimera. Also
bearing in mind that strdup is a system reserved name, my version
(with a #include <stdlib.h>) is:

char *dupstr(const char *str) {
char *dest, *temp;

if (dest = malloc(1 + strlen(str))) {
temp = dest;
while (*temp++ = *str++) continue;
}
return dest;
}

and I am willing to let it go boom when str is NULL, for early
warning etc. of problems.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Joe Wright]

Richard Heathfield wrote:

pete said:

<snip>

>Intsead of using realloc in a loop,
I think most programmers would write strdup with
one function call to strlen and one to malloc and one to strcpy.

memcpy, surely? Why measure the string twice?

Huh? strcpy doesn't measure anything.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---