fopen problem

P

pjlsr

It's close to twenty years since I used the C language and at that time
I was doing only floating point computational work, nothing with
strings or reading files. I tried to use fopen in the following manner.
a file name is entered by keyboard , fgets is used to read the name.
printf is used to confirm that the name was correctly read. Then
infile=fopen("filename","r") is used to open the file which very
definitly exists. It returns '0' as the ptr( I think that is the term),
which makes me suspicious. Then fgets is used to read a line from the
supposedly open file. This causes a stack error exception and a
stackdump.

I think fopen is where the problem is because it is supposed to return
a small positive integer. To me '0' is not a small positive integer.

I really don't want to get into installing c++ or something like that.
I currently using Gcc in CYGWIN to do the compiling.

Any suggestions anyone?

Pete
 
R

Robert Gamble

[I accidentally hit "reply to author" the first time, I am reposting to
the group.]

It's close to twenty years since I used the C language and at that time
I was doing only floating point computational work, nothing with
strings or reading files. I tried to use fopen in the following manner.
a file name is entered by keyboard , fgets is used to read the name.
printf is used to confirm that the name was correctly read. Then
infile=fopen("filename","r") is used to open the file which very
definitly exists. It returns '0' as the ptr( I think that is the term),
which makes me suspicious. Then fgets is used to read a line from the
supposedly open file. This causes a stack error exception and a
stackdump.

I think fopen is where the problem is because it is supposed to return
a small positive integer. To me '0' is not a small positive integer.

fopen returns a FILE pointer on success, NULL (0) on error, your fopen
call is obviously failing. You then call fgets with the NULL pointer
returned from fopen which invokes undefined behavior, the effects of
which may include a "stack error exception", whatever that is.
You said you were reading the filename with fgets, fgets will store the
newline in the buffer if there is room, does the name of the file you
are trying to open end with a newline? Are you removing the newline
from the buffer before passing it to fopen? If you have any more
questions, please post a small but complete and compilable example that
produces the undesired behavior.

Robert Gamble
 
G

Gordon Burditt

It's close to twenty years since I used the C language and at that time
I was doing only floating point computational work, nothing with
strings or reading files. I tried to use fopen in the following manner.
a file name is entered by keyboard , fgets is used to read the name.
printf is used to confirm that the name was correctly read. Then

fgets() returns a string with a trailing newline (unless your entry
is longer than the buffer supplied to fgets). Did you remove it
before passing it to fopen()? You should unless you really have
files with names containing newlines, which is pretty unusual.
infile=fopen("filename","r") is used to open the file which very
definitly exists. It returns '0' as the ptr( I think that is the term),
which makes me suspicious.

If fopen() returns NULL, it failed. This apparently happened in
your program.
Then fgets is used to read a line from the
supposedly open file. This causes a stack error exception and a
stackdump.

Passing NULL to fgets() invokes the wrath of undefined behavior.
You should check the value returned by fopen() for being equal to
NULL before attempting to use it. If it is equal to NULL, print
an error message and do not attempt using it.
I think fopen is where the problem is because it is supposed to return
a small positive integer.

fopen() returns a pointer, *NOT* a small positive integer. If it
returns NULL, it failed.
To me '0' is not a small positive integer.

Forget the small positive integer. NULL is not guaranteed to be
represented as 0xdeadbeef, even on 32-bit machines, and it is
sometimes represented as 0.
I really don't want to get into installing c++ or something like that.
I currently using Gcc in CYGWIN to do the compiling.

Any suggestions anyone?

When you print out the filename you got to check it, put it in
quotes:

printf("The file name is '%s'\n", filename);

When it prints:

The file name is 'foobar.txt
'

you'll know you forgot to remove the trailing newline.

Also, always check if the return value of fopen() is equal to NULL
before trying to use it.

Although fopen() is not guaranteed to never return a non-zero small
positive integer as a pointer, there's a good chance that if it
does something is seriously wrong.

Gordon L. Burditt
 
K

Keith Thompson

I think fopen is where the problem is because it is supposed to return
a small positive integer. To me '0' is not a small positive integer.

You're probably confusing fopen() with open().

<OT>
The open() is not defined by the C standard; it's part of POSIX.
open() returns a small positive integer, known as a "file descriptor",
or -1 on error.
</OT>

fopen() is a standard C function that returns a pointer value (of type
FILE*); the returned values is NULL on error. (Pointers are not
integers.)
 
P

pjlsr

Thanks for the replies. Yep, per the print test there is a newline
hung on the end of the filename! So the next question is how to remove
the little bugger, since in general I don't know beforehand how long
the filename will be.

Pete
 
M

Martin Ambuhl

It's close to twenty years since I used the C language and at that time
I was doing only floating point computational work, nothing with
strings or reading files. I tried to use fopen in the following manner.
a file name is entered by keyboard , fgets is used to read the name.
printf is used to confirm that the name was correctly read. Then
infile=fopen("filename","r") is used to open the file which very
definitly exists. It returns '0' as the ptr( I think that is the term),
which makes me suspicious.

Did you remember to remove the '\n' from the line with the filename?
 
M

Martin Ambuhl

Thanks for the replies. Yep, per the print test there is a newline
hung on the end of the filename! So the next question is how to remove
the little bugger, since in general I don't know beforehand how long
the filename will be.

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

int main(void)
{
char fname[FILENAME_MAX+1], *nl;
FILE *fp;
printf("What is the filename? ");
fflush(stdout);
if (!fgets(fname, sizeof fname, stdio)) {
fprintf(stderr, "I couldn't read that for some reason.\n");
exit(EXIT_FAILURE);
}
if ((nl = strchr(fname,'\n'))) *nl = 0;
if (!(fp = fopen(fname,"r"))) {
fprintf(stderr, "\"%s\" could not be opened for reading.\n",
fname);
exit(EXIT_FAILURE);
}
fclose(fp);
return 0;
}
 
E

Emmanuel Delahaye

(e-mail address removed) a écrit :
It's close to twenty years since I used the C language and at that time
I was doing only floating point computational work, nothing with
strings or reading files. I tried to use fopen in the following manner.
a file name is entered by keyboard , fgets is used to read the name.
printf is used to confirm that the name was correctly read. Then
infile=fopen("filename","r") is used to open the file which very

Try that :

infile=fopen(filename,"r");

and if you are usig fgets() to get the name from the user, be sure that
you have removed the trailing '\n' if exists.

As long as infile is 0 (NULL) don't go further. The opening of the file
has failed.
 
E

Emmanuel Delahaye

(e-mail address removed) a écrit :
It's close to twenty years since I used the C language and at that time
I was doing only floating point computational work, nothing with
strings or reading files. I tried to use fopen in the following manner.
a file name is entered by keyboard , fgets is used to read the name.
printf is used to confirm that the name was correctly read. Then
infile=fopen("filename","r") is used to open the file which very

Try that :

infile=fopen(filename,"r");

and if you are using fgets() to get the name from the user, be sure that
you have removed the trailing '\n' if exists.

As long as infile is 0 (NULL) don't go further. The opening of the file
has failed.
 
M

Michael Wojcik

<OT>
The open() is not defined by the C standard; it's part of POSIX.
open() returns a small positive integer, known as a "file descriptor",
or -1 on error.
</OT>

<OT TYPE="still">
POSIX / SUS open returns a small *nonnegative* integer on success. 0
is a valid descriptor value. (I'm amazed at how often I encounter
bugs in POSIX programs due to assuming 0 isn't a valid descriptor.)
</OT>

--
Michael Wojcik (e-mail address removed)

Reversible CA's are -automorphisms- on shift spaces. It is a notorious
fact in symbolic dynamics that describing such things on a shift of finite
type are -fiendishly- difficult. -- Chris Hillman
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

fopen 20
Problem with fopen 13
fopen 17
fopen question 7
fopen() questions 17
open/fopen read/fread in multithreaded environment. 1
fopen() with full path affecting subsequent fopen calls 4
Is fopen blocked? 7

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top