Program repeats itself, pointer trouble I suspect.

[Neil]

Hello all!
I wrote program with a array of pointers, and I suspect they are
pointing at each other in the Do ...While loop.
Something is messed up with the increment variable word. A program
clip of what I'm talking about.

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

int main(void)
{
char string[50] = {"Have a nice day folks"};
char *line_ptr;
char *list[20] = { '\0' }; //Initialize the array of pointers to
NULL.
int word = 0;

line_ptr = strtok(string, " ");

do
{
list[word] = line_ptr;
word++;
line_ptr = strtok(NULL," ");
} while (line_ptr != NULL);

return 0;
}
It's kinda weird, cause the program repeats itself when I run it. I
left out the output section, cause I know it works fine. In the
debugger it works OK. Is there a memory leak? Do you need to assign
pointers to NULL after you use them? Should I free up the memory from
the array of pointers before the program terminates? What is the best
way handle pointers after your done with them?

Thanks for all your help
Neil

[Old Wolf]

On Feb 15, 1:50 pm, "Neil" <[e-mail]:

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

int main(void)
{
char string[50] = {"Have a nice day folks"};
char *line_ptr;
char *list[20] = { '\0' };

{ 0 } does the same thing and makes a bit more sense.

int word = 0;

line_ptr = strtok(string, " ");

do
{
list[word] = line_ptr;
word++;
line_ptr = strtok(NULL," ");
} while (line_ptr != NULL);

return 0;}

It's kinda weird, cause the program repeats itself when I run it.

This program is fine. What do you mean by 'repeats itself' ?
This program generates no output.

In the debugger it works OK. Is there a memory leak?

No

>Do you need to assign pointers to NULL after you use them?

No

Should I free up the memory from the array of pointers before the
program terminates?

No

What is the best way handle pointers after your done with them?

Take no special action.

I left out the output section, cause I know it works fine.

Apparently not...

[Barry Schwarz]

On 14 Feb 2007 16:50:11 -0800, "Neil" <ne*********@hotmail.comwrote:

>Hello all!
I wrote program with a array of pointers, and I suspect they are
pointing at each other in the Do ...While loop.
Something is messed up with the increment variable word. A program
clip of what I'm talking about.

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

int main(void)
{
char string[50] = {"Have a nice day folks"};
char *line_ptr;
char *list[20] = { '\0' }; //Initialize the array of pointers to
NULL.

This is why you should not use // style comments in usenet.

If you want assign each of the 20 pointer in the array the NULL value,
use NULL. While 0 and '\0' will both work, they are visually
misleading. Someone might be tempted to think that the pointers point
to a char containing '\0'.

>int word = 0;

line_ptr = strtok(string, " ");

do
{
list[word] = line_ptr;
word++;
line_ptr = strtok(NULL," ");
} while (line_ptr != NULL);

return 0;
}
It's kinda weird, cause the program repeats itself when I run it. I
left out the output section, cause I know it works fine. In the

Define repeat.

The archives are full of messages where the error was in the section
omitted by the poster because "it works." Post a compilable example
that demonstrates the behavior in question and let us help you find
the problem.

>debugger it works OK. Is there a memory leak? Do you need to assign

You cannot have a memory leak without dynamic allocation.

>pointers to NULL after you use them? Should I free up the memory from

Unless you test a pointer for NULL, you never need to reset it to
NULL.

>the array of pointers before the program terminates? What is the best

Any attempt to free memory that you did not allocate will invoke
undefined behavior.

>way handle pointers after your done with them?

The same way you handle an object of any other type when you are done
with it. In most cases, it is sufficient to simply not use it in any
subsequent code.
Remove del for email

[Beej]

On Feb 14, 4:50 pm, "Neil" <[e-mail]:

line_ptr = strtok(string, " ");

Unless you're sure you're always going to have a token, you should
probably check line_ptr for NULL here, too.

Here's a compact form of that, if you don't mind assignments in your
expressions:

if ((p = strtok(string, " ")) != NULL) {
do {
printf("Token: %s\n", p);
} while ((p = strtok(NULL, " ")) != NULL);
}

do
{
list[word] = line_ptr;
word++;
line_ptr = strtok(NULL," ");
} while (line_ptr != NULL);

Here is my output when I ran it.

'Have'
'a'
'nice'
'day'
'folks'

Looks fine to me. What's your output?

-Beej

[Christopher Layne]

Neil wrote:

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

int main(void)
{
char string[50] = {"Have a nice day folks"};
char *line_ptr;
char *list[20] = { '\0' }; *//Initialize the array of pointers to

Cleaner version:

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

enum constants {
STRING_MAX = 50,
WORD_MAX = 20
};

int main(void)
{
char string[STRING_MAX] = "Have a nice day folks";
char *word[WORD_MAX];
int i;

for (i = 0; i < WORD_MAX; i++) {
if ((word[i] = strtok(i ? NULL : string, " ")) == NULL)
break;
fprintf(stdout, "word[%d] = %s\n", i, word[i]);
}

return 0;
}

[Richard Heathfield]

Old Wolf said:

On Feb 15, 1:50 pm, "Neil" <[e-mail]:

>>
do
{
list[word] = line_ptr;
word++;
line_ptr = strtok(NULL," ");
} while (line_ptr != NULL);

return 0;}

It's kinda weird, cause the program repeats itself when I run it.

This program is fine.

You think so? I don't think you read it carefully enough.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Ben Bacarisse]

"Neil" <ne*********@hotmail.comwrites:

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

int main(void)
{
char string[50] = {"Have a nice day folks"};
char *line_ptr;
char *list[20] = { '\0' }; /* Initialize the array of pointers to NULL.*/
int word = 0;

line_ptr = strtok(string, " ");

do
{
list[word] = line_ptr; /* MARK */
word++;
line_ptr = strtok(NULL," ");
} while (line_ptr != NULL);

Other than and hint in a reply to another reply, no one has pointed
out that you are in danger of accessing outside the bounds of your
array "list".

If it reasonable (is it ever?) to simply discard tokens that don't
fit, you can write:

if (word < 20) list[word] = line_ptr;

where I put /* MARK */ in your code.

I don't know of this is the source of your problem, because the
description is rather vague.

--
Ben.

[Old Wolf]

On Feb 15, 7:19 pm, Richard Heathfield <[e-mail]:

Old Wolf said:

On Feb 15, 1:50 pm, "Neil" <[e-mail]:

do
{
list[word] = line_ptr;
word++;
line_ptr = strtok(NULL," ");
} while (line_ptr != NULL);

return 0;}

It's kinda weird, cause the program repeats itself when I run it.

This program is fine.

You think so? I don't think you read it carefully enough.

By 'fine' I mean that the OP's code doesn't contain any bugs.
Of course I would not pedantic about the use of C99 features,
or bugs introduced by wordwrapping during the posting process.

Are you perhaps referring to the fact that the program might
break if its source is modified to introduce a bug, as
suggested by Ben Bacarisse?
If not, then please be more explicit.

[Ben Bacarisse]

"Old Wolf" <ol*****@inspire.net.nzwrites:

Are you perhaps referring to the fact that the program might
break if its source is modified to introduce a bug, as
suggested by Ben Bacarisse?

I'm not seeing it. Can you post a correction to my message (or
explain it to me and I'll post a correction)?

--
Ben.

[Old Wolf]

On Feb 16, 12:46 pm, Ben Bacarisse <[e-mail]:

"Old Wolf" <[e-mail]:

Are you perhaps referring to the fact that the program might
break if its source is modified to introduce a bug, as
suggested by Ben Bacarisse?

I'm not seeing it. Can you post a correction to my message (or
explain it to me and I'll post a correction)?

Your message appears to be saying that the program could
break if the input string were modified to have more than
20 words in it, which would be a bug. But the original
post only had 4 words in the string, so there is no problem.

(Of course it is not a bad idea to add in checking, as
you suggested).

[Neil]

On Feb 14, 7:24 pm, Barry Schwarz <[e-mail]:

On 14 Feb 2007 16:50:11 -0800, "Neil" <[e-mail]:

Hello all!

I wrote program with a array of pointers, and I suspect they are
pointing at each other in the Do ...While loop.
Something is messed up with the increment variable word. A program
clip of what I'm talking about.

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

int main(void)
{
char string[50] = {"Have a nice day folks"};
char *line_ptr;
char *list[20] = { '\0' }; //Initialize the array of pointers to
NULL.

This is why you should not use // style comments in usenet.

If you want assign each of the 20 pointer in the array the NULL value,
use NULL. While 0 and '\0' will both work, they are visually
misleading. Someone might be tempted to think that the pointers point
to a char containing '\0'.

int word = 0;

line_ptr = strtok(string, " ");

do
{
list[word] = line_ptr;
word++;
line_ptr = strtok(NULL," ");
} while (line_ptr != NULL);

return 0;
}
It's kinda weird, cause the program repeats itself when I run it. I
left out the output section, cause I know it works fine. In the

Define repeat.

It starts again from main(), There must be problem elsewhere.
-Neil

[Neil]

On Feb 15, 7:56 am, Ben Bacarisse <[e-mail]:

"Neil" <[e-mail]:

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

int main(void)
{
char string[50] = {"Have a nice day folks"};
char *line_ptr;
char *list[20] = { '\0' }; /* Initialize the array of pointers to NULL.*/
int word = 0;

line_ptr = strtok(string, " ");

do
{
list[word] = line_ptr; /* MARK */
word++;
line_ptr = strtok(NULL," ");
} while (line_ptr != NULL);

Other than and hint in a reply to another reply, no one has pointed
out that you are in danger of accessing outside the bounds of your
array "list".

If it reasonable (is it ever?) to simply discard tokens that don't
fit, you can write:

if (word < 20) list[word] = line_ptr;

where I put /* MARK */ in your code.

I don't know of this is the source of your problem, because the
description is rather vague.

--
Ben.- Hide quoted text -

- Show quoted text -

Ben your probably right, but I didn't want to go through whole
program, just the code clip I
mentioned. Thanks for the help, I'll try that....

-Neil

[Neil]

On Feb 14, 8:45 pm, "Beej" <[e-mail]:

On Feb 14, 4:50 pm, "Neil" <[e-mail]:

line_ptr = strtok(string, " ");

Unless you're sure you're always going to have a token, you should
probably check line_ptr for NULL here, too.

Here's a compact form of that, if you don't mind assignments in your
expressions:

if ((p = strtok(string, " ")) != NULL) {
do {
printf("Token: %s\n", p);
} while ((p = strtok(NULL, " ")) != NULL);

}

do
{
list[word] = line_ptr;
word++;
line_ptr = strtok(NULL," ");
} while (line_ptr != NULL);

Here is my output when I ran it.

'Have'
'a'
'nice'
'day'
'folks'

Looks fine to me. What's your output?

-Beej

Beej the output section is a function that I left off, however the
program does begin
at the start, or the program crashes, from what I tried recently.
I'm trying to isolate the problem. thanks.
-Neil.

[Ben Bacarisse]

"Old Wolf" <ol*****@inspire.net.nzwrites:

On Feb 16, 12:46 pm, Ben Bacarisse <[e-mail]:

>"Old Wolf" <[e-mail]:

Are you perhaps referring to the fact that the program might
break if its source is modified to introduce a bug, as
suggested by Ben Bacarisse?

I'm not seeing it. Can you post a correction to my message (or
explain it to me and I'll post a correction)?

Your message appears to be saying that the program could
break if the input string were modified to have more than
20 words in it, which would be a bug. But the original
post only had 4 words in the string, so there is no problem.

Ah, OK. Crossed wires.

(Of course it is not a bad idea to add in checking, as
you suggested).

....but probably not in any way a fix for the OP's problem if it failed
with a four token string.

--
Ben.

[Neil]

On Feb 14, 7:24 pm, Barry Schwarz <[e-mail]:
This is why you should not use // style comments in usenet.
Huh?....Didn't know that.

Barry, I'm using an old Borland Turbo C++ for DOS Compiler to write
this program, it's crashed a couple of times writing I what I think
what looks like elementry code.

If you don't intialize a pointer, but you declared it main() and just
leave it.
Does this present a problem after the program terminates?

Can two char pointers in an array of pointers point to each other
after the program terminates?

Thanks for tip..

-Neil

[Neil]

On Feb 15, 7:18 pm, "Neil" <[e-mail]:

On Feb 14, 7:24 pm, Barry Schwarz <[e-mail]:
This is why you should not use // style comments in usenet.

Huh?....Didn't know that.

Barry, I'm using an old Borland Turbo C++ for DOS Compiler to write
this program, it's crashed a couple of times writing I what I think
what looks like elementry code.

If you don't intialize a pointer, but you declared it main() and just
leave it.

I ment inside main() :)

-Neil

[Neil]

On Feb 14, 9:00 pm, Christopher Layne <[e-mail]:

Neil wrote:

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

int main(void)
{
char string[50] = {"Have a nice day folks"};
char *line_ptr;
char *list[20] = { '\0' }; //Initialize the array of pointers to

Cleaner version:

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

enum constants {
STRING_MAX = 50,
WORD_MAX = 20

};

int main(void)
{
char string[STRING_MAX] = "Have a nice day folks";
char *word[WORD_MAX];
int i;

for (i = 0; i < WORD_MAX; i++) {
if ((word[i] = strtok(i ? NULL : string, " ")) == NULL)
break;
fprintf(stdout, "word[%d] = %s\n", i, word[i]);
}

return 0;

Huh? ........Better then mine..........but OK.
I'll try that.
Thanks Chris..
-Neil

[Barry Schwarz]

On 15 Feb 2007 18:18:01 -0800, "Neil" <ne*********@hotmail.comwrote:

>On Feb 14, 7:24 pm, Barry Schwarz <[e-mail]:
This is why you should not use // style comments in usenet.
Huh?....Didn't know that.

Barry, I'm using an old Borland Turbo C++ for DOS Compiler to write
this program, it's crashed a couple of times writing I what I think
what looks like elementry code.

Post a compilable example of the code that exhibits the behavior.

>
If you don't intialize a pointer, but you declared it main() and just
leave it.
Does this present a problem after the program terminates?

Unless you attempt to evaluate its value, the fact that a pointer is
uninitialized (technically called indeterminate) cannot be a problem.

>
Can two char pointers in an array of pointers point to each other
after the program terminates?

Unless you have a very strange operating system, after your program
terminates none of your objects exist. Since they no longer exist,
one of the many things they don't do is point anywhere, let alone to
each other.

While your program is running, it is still not possible for one char
pointer to point to another. By definition, a char pointer must point
to a char (if it points anywhere). It makes no difference whether the
pointers are in an array or not.
Remove del for email

[Neil]

On Feb 15, 9:28 pm, Barry Schwarz <[e-mail]:
Post a compilable example of the code that exhibits the behavior.

Barry, I would if I knew where the problem is in the program..
Obviouly the pointers are not causing the problem.

Thanks for all your help
-Neil

[Richard Heathfield]

Neil said:

On Feb 15, 9:28 pm, Barry Schwarz <[e-mail]:
Post a compilable example of the code that exhibits the behavior.

Barry, I would if I knew where the problem is in the program..

If you knew where the problem was, you wouldn't need to ask about it at
all. Since you don't know where the problem was, it makes sense to post
the whole program.

Obviouly the pointers are not causing the problem.

But you just said you don't know where the problem is.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Default User]

Neil wrote:

On Feb 15, 9:28 pm, Barry Schwarz <[e-mail]:
Post a compilable example of the code that exhibits the behavior.

Barry, I would if I knew where the problem is in the program..
Obviouly the pointers are not causing the problem.

We need a complete, minimal program that demonstrates the problem.
There three conditions there.

1. Complete - A program that can be cut and pasted in our compilers if
we choose, but at the very least we know is not missing something.

2. Minimal - The program reduced down as much as possible. That means
removing parts where you can to simplify it, but still produces the
failing behavior. Often the process will reveal the section with the
bug, but at least you will make the review process easier.

3. Demonstrates the problem - The code you give us should be able to
produce the exact condition you are experiencing. In addition, you need
to tell us what the program was supposed to do, and what it did
instead. If it is failing to compile, transcribe exactly or
(preferably) cut and paste the compiler messages.


Brian

[santosh]

Default User wrote:

Neil wrote:

On Feb 15, 9:28 pm, Barry Schwarz <[e-mail]:
Post a compilable example of the code that exhibits the behavior.

Barry, I would if I knew where the problem is in the program..
Obviouly the pointers are not causing the problem.

We need a complete, minimal program that demonstrates the problem.
There three conditions there.

1. Complete - A program that can be cut and pasted in our compilers if
we choose, but at the very least we know is not missing something.

2. Minimal - The program reduced down as much as possible. That means
removing parts where you can to simplify it, but still produces the
failing behavior. Often the process will reveal the section with the
bug, but at least you will make the review process easier.

3. Demonstrates the problem - The code you give us should be able to
produce the exact condition you are experiencing. In addition, you need
to tell us what the program was supposed to do, and what it did
instead. If it is failing to compile, transcribe exactly or
(preferably) cut and paste the compiler messages.

Might be a good idea to save this reply for quickly responding to
similar situations in the future.

[Neil]

On Feb 16, 1:10 am, Richard Heathfield <[e-mail]:

Since you don't know where the problem was, it makes sense to post the
whole program.

Richard Heathfield
"Usenet is a strange place"

True...But I fixed the problem late night, knowing what you everyone
told me about pointers, It works just fine now.

Reason, why I didn't post the whole program was I didn't have copy of
it with me at work, I was sure that I could find a solution for it
soon, as I did.

Richard thanks for your help, Have a good weekend!!

-Neil

[Neil]

On Feb 16, 11:57 am, "Default User" <[e-mail]:

Neil wrote:

On Feb 15, 9:28 pm, Barry Schwarz <[e-mail]:
Post a compilable example of the code that exhibits the behavior.

Barry, I would if I knew where the problem is in the program..
Obviouly the pointers are not causing the problem.

We need a complete, minimal program that demonstrates the problem.
There three conditions there.

1. Complete - A program that can be cut and pasted in our compilers if
we choose, but at the very least we know is not missing something.

2. Minimal - The program reduced down as much as possible. That means
removing parts where you can to simplify it, but still produces the
failing behavior. Often the process will reveal the section with the
bug, but at least you will make the review process easier.

3. Demonstrates the problem - The code you give us should be able to
produce the exact condition you are experiencing. In addition, you need
to tell us what the program was supposed to do, and what it did
instead. If it is failing to compile, transcribe exactly or
(preferably) cut and paste the compiler messages.

Brian

Brain Yeh right, I make a note of that next time, fortunatly I solved
the problem late last night. OK.

[Neil]

On Feb 16, 12:32 pm, "santosh" <[e-mail]:

Default User wrote:

Neil wrote:

On Feb 15, 9:28 pm, Barry Schwarz <[e-mail]:
Post a compilable example of the code that exhibits the behavior.

Barry, I would if I knew where the problem is in the program..
Obviouly the pointers are not causing the problem.

We need a complete, minimal program that demonstrates the problem.
There three conditions there.

1. Complete - A program that can be cut and pasted in our compilers if
we choose, but at the very least we know is not missing something.

2. Minimal - The program reduced down as much as possible. That means
removing parts where you can to simplify it, but still produces the
failing behavior. Often the process will reveal the section with the
bug, but at least you will make the review process easier.

3. Demonstrates the problem - The code you give us should be able to
produce the exact condition you are experiencing. In addition, you need
to tell us what the program was supposed to do, and what it did
instead. If it is failing to compile, transcribe exactly or
(preferably) cut and paste the compiler messages.

Might be a good idea to save this reply for quickly responding to
similar situations in the future.

OK ........will do,

[santosh]

Neil wrote:

On Feb 16, 1:10 am, Richard Heathfield <[e-mail]:

[quote markers added]

Since you don't know where the problem was, it makes sense to post the
whole program.

<snip>

True...But I fixed the problem late night, knowing what you everyone
told me about pointers, It works just fine now.

<snip>

Please use a standard quotation character like '>' for the text you
quote. Google Groups should quote the message by default. Why are you
removing them?

[Neil]

On Feb 16, 11:57 am, "Default User" <[e-mail]:

Neil wrote:

On Feb 15, 9:28 pm, Barry Schwarz <[e-mail]:
Post a compilable example of the code that exhibits the behavior.

Barry, I would if I knew where the problem is in the program..
Obviouly the pointers are not causing the problem.

We need a complete, minimal program that demonstrates the problem.
There three conditions there.

1. Complete - A program that can be cut and pasted in our compilers if
we choose, but at the very least we know is not missing something.

2. Minimal - The program reduced down as much as possible. That means
removing parts where you can to simplify it, but still produces the
failing behavior. Often the process will reveal the section with the
bug, but at least you will make the review process easier.

3. Demonstrates the problem - The code you give us should be able to
produce the exact condition you are experiencing. In addition, you need
to tell us what the program was supposed to do, and what it did
instead. If it is failing to compile, transcribe exactly or
(preferably) cut and paste the compiler messages.

Brian

Damn.......I spelled your name wrong in the last post.
In C, your not allowed to misspell your variable names either,
Brian....Have a good weekend.

Neil :)

[Neil]

On Feb 16, 1:10 am, Richard Heathfield

But you just said you don't know where the problem is.

True Richard, I only suspected the pointers where at fault, However
Barry gave me some information that was vital in my search for the
problem, then I ruled out that the posted section of the program was
not fault. Thanks anyway.

-Neil.