 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Guest
|
 Posted: Sat May 19, 2007 9:11 am Post subject: Segmentation fault with array |
 |
|
Hi, I'm getting confused with arrays and hope someone can shed light
on my code.
I wrote this to try and learn about files and arrays as I thought if I
could grab each element and place them into an array I can manipulate
the stings from the file with array indexes.
Perhaps there's a better method but I'm learning.
#include <stdio.h>
#include <stdlib.h>
int main()
{
char c;
int num=0;
int count=0;
int i;
char instring[10];
FILE * fp;
if((fp=fopen("testdata.txt","r"))==NULL)
{
printf("Error in openning the file.\n");
exit(2);
}
while(!feof(fp))
{
num++;
if ((c = getc(fp))==EOF)
{
printf("EOF reached \n");
break;
}
else
{
if (c != '\0')
{
instring[count] =c;
printf("count = %d, instring = %c\n",count,instring[count]);
count++;
}
}
}
i=0;
printf("char 3 is %c\n",instring[i+3]);
return 0;
}
The testdata.txt contains
ab$
e.f
1we
@\/
"@'
:]_
..
When I execute the program I get the following result:
count = 0, instring = a
count = 1, instring = b
count = 2, instring = $
count = 3, instring =
count = 4, instring = e
count = 5, instring = .
count = 6, instring = f
count = 7, instring =
count = 8, instring = 1
count = 9, instring = w
count = 10, instring = e
count = 11, instring =
count = 12, instring = @
count = 13, instring = \
count = 14, instring = /
count = 15, instring =
count = 16, instring = "
count = 17, instring = @
count = 18, instring = '
count = 19, instring =
Segmentation Fault (core dumped)
My question is if the instring has 10 elements then why is it printing
out to element 19 ?
If I put a large number, such as char instring[150], then it will work
Have I misunderstood arrays completely ?
Pat |
|
| Back to top |
|
 |
Chris Dollin
Guest
|
| Posted: Sat May 19, 2007 9:11 am Post subject: Re: Segmentation fault with array |
|
|
Michael wrote:
| Quote: | Ian answered your actual question, so let me point out another problem
in your code:
char c;
...
if ((c = getc(fp))==EOF)
The function getc returns an integer. I know, that's crazy, but
that's the way it is.
|
Suppose `getc` returned a `char`. What `char` value would you
pick to represent EOF and hence disallow from appearing in any
FILE* input?
Remember that FILE*s can be reading "binary" files.
--
Three-Way Secret Hedgehog
A rock is not a fact. A rock is a rock. |
|
| Back to top |
|
|
Ian Collins
Guest
|
| Posted: Sat May 19, 2007 9:11 am Post subject: Re: Segmentation fault with array |
|
|
ptq2238 (AT) gmail (DOT) com wrote:
| Quote: | Hi, I'm getting confused with arrays and hope someone can shed light
on my code.
I wrote this to try and learn about files and arrays as I thought if I
could grab each element and place them into an array I can manipulate
the stings from the file with array indexes.
Perhaps there's a better method but I'm learning.
#include <stdio.h
#include <stdlib.h
int main()
{
char c;
int num=0;
int count=0;
int i;
char instring[10];
FILE * fp;
if((fp=fopen("testdata.txt","r"))==NULL)
{
printf("Error in openning the file.\n");
exit(2);
}
while(!feof(fp))
{
num++;
if ((c = getc(fp))==EOF)
{
printf("EOF reached \n");
break;
}
else
{
if (c != '\0')
{
instring[count] =c;
printf("count = %d, instring = %c\n",count,instring[count]);
count++;
}
}
}
i=0;
printf("char 3 is %c\n",instring[i+3]);
return 0;
}
My question is if the instring has 10 elements then why is it printing
out to element 19 ?
If I put a large number, such as char instring[150], then it will work
Have I misunderstood arrays completely ?
You have an array of single characters, which you then fill, and keep |
writing to without checking if you have written past the end. It looks
like you intended to read lines, rather than single characters.
--
Ian Collins. |
|
| Back to top |
|
|
Michael
Guest
|
| Posted: Sat May 19, 2007 9:11 am Post subject: Re: Segmentation fault with array |
|
|
Ian answered your actual question, so let me point out another problem
in your code:
| Quote: | char c;
....
if ((c = getc(fp))==EOF)
|
The function getc returns an integer. I know, that's crazy, but
that's the way it is. (Not all standard library functions have good
interfaces.) The comparison to EOF can fail (I forget whether it
always does or only does on certain implementations) if c is a
character instead of an int.
Michael |
|
| Back to top |
|
|
Guest
|
| Posted: Sun May 20, 2007 9:11 am Post subject: Re: Segmentation fault with array |
|
|
Thank you for everyone's reply.
I've followed through with the suggestions and it's now working.
I think I would be better off by drawing up a diagram of my logic
first next time. |
|
| Back to top |
|
|
Michael
Guest
|
| Posted: Sun May 20, 2007 9:11 am Post subject: Re: Segmentation fault with array |
|
|
On May 19, 12:23 am, Chris Dollin <e...@electrichedgehog.net> wrote:
| Quote: | Michael wrote:
Ian answered your actual question, so let me point out another problem
in your code:
char c;
...
if ((c = getc(fp))==EOF)
The function getc returns an integer. I know, that's crazy, but
that's the way it is.
Suppose `getc` returned a `char`. What `char` value would you
pick to represent EOF and hence disallow from appearing in any
FILE* input?
Remember that FILE*s can be reading "binary" files.
--
|
Alternately, suppose you wrote a function where the description is
"read the next thing and return an int, not a char." Would you call
such a function getc?
Or suppose your description of your function was: sometimes return one
thing, sometimes return another (e.g., return a char except if you
don't, because you've reached end of file, or if an error occurs).
Would you think that, perhaps, a better interface was in order?
Or suppose you developed an interface that was commonly misused, and
in fact, was incredibly easy to misuse, because you had a combination
of: 1) outputs that mean different things, 2) a bad name, and 3) a
common misuse pattern that can not be caught by the compiler. If you
were the one to develop such an interface, I would blame you, not the
poor schmucks who were confused by your inanity. Although I suppose
that the typical thing is design such goofiness, document it, and them
blame the person who uses the interface for not reading the
documentation closely enough, regardless of how poorly the interface
is designed.
</rant>
Michael |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
