i am using this piece of code in my program which reads characters from a file and operates on them
the code works fine but after the execution, i get the following runtime errorCode:char ch; do { ch=fgetc(FILE_NAME); switch(ch) /// some stuff } while (ch!=EOF)
Runtime error R6001
-null pointer assignment
what could be the possible reason?
Tnx
What is FILE_NAME? Is it a string? If so, that's wrong.
Incidentally, your loop is incorrect. Something more like this would stop you from using EOF as a char:
Also, ch needs to be of type int, not a char, because that's what fgetc() returns.Code:while((ch=fget(pFile)) != EOF) /* Note: pFile needs to be a valid FILE * */ { .... }
int fgetc( FILE *stream );
1. ch should be int
2. check if it is not EOF before using in the switch statement
3. parameter for the fgetc should be FILE* and not filename
All problems in computer science can be solved by another level of indirection,
except for the problem of too many layers of indirection.
– David J. Wheeler
And EOF doesn't fit into a char
Actually, that's what I meant to say.Originally Posted by zacs7
And EOF doesn't fit into a char
I should have clarified my last statement. fgetc() returns an int because a char can't hold EOF, but an int can.....
the loop statement does not solve the problem....
FILE_NAME is a pointer not a string
and i guess ch being char does not make any difference as ultimately i think you can even print an integer as a char whose ascii value is that int
declaring ch as int doesn't solve the prob either.....
It solves another obvious problem you might have come running back here for.
A pointer to what? A FILE object? The first element of a char array?
If you use a char, you could get weird behavior in your code when you do receive EOF.
I've seen it happen before.
You need an int if you are expecting EOF.
Maybe not, but it definitely fixes another problem that should be addressed.
I'd rather tell you everything wrong with your code now than wait for you to come back with one problem after another to be fixed in the order of your choosing.
thnx man for these advices....ill try to mend them next time on...
but the problem still persists....
and yes pointer to the file object
The problem you speak of does not appear to be directly related to the code you posted.
Editx2: It appears you're possibly using a really old DOS compiler. Is this the case? If so, you really should consider upgrading to a free Windows compiler.
Incidentally, are you making sure that fopen() is not returning NULL?
Last edited by MacGyver; 05-31-2007 at 04:48 AM.
What does "after the execution" mean? After the execution of the block of code you posted, or after the execution of the entire program (i.e., does it crash right at the end, before it's supposed to exit)? Be more specific. The snippet you posted is too vague to help anything.
Because he's using a crappy DOS compiler which can only detect NULL pointer assignments by looking at the memory just after where NULL points to see if it's been written to.
With a real operating system, the program would be dead as soon as it tried to dereference NULL (and a debugger would take you right to the culprit).
But DOS only gives you a faint echo of past trouble, and you have to guess where it all went wrong. It certainly gives no help in trying to read via NULL, only write via NULL.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Moving on, Why don't you get a good compiler as Salem suggested earlier?
There are better DOS compilers... See the FAQ.
When you used fopen
did you do it like this?
or like this:Code:fp = fopen("C:\File.txt","r");
Code:fp = fopen("C:\\File.txt","r");
thank you all for your replies....
compiling the code in a new compiler solves the problem.
