Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > fopen problem

Reply
Thread Tools

fopen problem

 
 
pjlsr@netscape.com
Guest
Posts: n/a
 
      10-14-2005
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

 
Reply With Quote
 
 
 
 
Robert Gamble
Guest
Posts: n/a
 
      10-14-2005
[I accidentally hit "reply to author" the first time, I am reposting to
the group.]

http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> 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

 
Reply With Quote
 
 
 
 
Gordon Burditt
Guest
Posts: n/a
 
      10-14-2005
>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
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      10-14-2005
(E-Mail Removed) writes:
[...]
> 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.)

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
 
Reply With Quote
 
pjlsr@netscape.com
Guest
Posts: n/a
 
      10-14-2005


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

 
Reply With Quote
 
Martin Ambuhl
Guest
Posts: n/a
 
      10-14-2005
(E-Mail Removed) wrote:
> 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?
 
Reply With Quote
 
Martin Ambuhl
Guest
Posts: n/a
 
      10-14-2005
(E-Mail Removed) wrote:
>
> 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;
}
 
Reply With Quote
 
Emmanuel Delahaye
Guest
Posts: n/a
 
      10-14-2005
(E-Mail 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.
 
Reply With Quote
 
Emmanuel Delahaye
Guest
Posts: n/a
 
      10-14-2005
(E-Mail 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.
 
Reply With Quote
 
Michael Wojcik
Guest
Posts: n/a
 
      10-14-2005

In article <(E-Mail Removed)>, Keith Thompson <(E-Mail Removed)> writes:
>
> <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 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
fopen() with full path affecting subsequent fopen calls Michel Rouzic C Programming 4 04-28-2008 04:48 PM
Problem with fopen vaddadi.chandu@gmail.com C Programming 3 01-29-2006 05:41 PM
What is up with fopen??? FOpen and local directories Nonee HTML 2 10-25-2005 09:18 PM
Problem with fopen, linux, and RS-232, possibly Gregory Graham C Programming 3 12-09-2004 06:48 AM
interesting problem in turbo C++, involving fopen git_cs C Programming 7 04-30-2004 09:43 PM



Advertisments