fopen problem

Discussion in 'C Programming' started by pjlsr@netscape.com, Oct 14, 2005.

  1. Guest

    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
     
    , Oct 14, 2005
    #1
    1. Advertising

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

    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
     
    Robert Gamble, Oct 14, 2005
    #2
    1. Advertising

  3. >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
     
    Gordon Burditt, Oct 14, 2005
    #3
  4. 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) <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.
     
    Keith Thompson, Oct 14, 2005
    #4
  5. Guest

    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
     
    , Oct 14, 2005
    #5
  6. 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?
     
    Martin Ambuhl, Oct 14, 2005
    #6
  7. 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;
    }
     
    Martin Ambuhl, Oct 14, 2005
    #7
  8. 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.
     
    Emmanuel Delahaye, Oct 14, 2005
    #8
  9. 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.
     
    Emmanuel Delahaye, Oct 14, 2005
    #9
  10. In article <>, Keith Thompson <> 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

    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
     
    Michael Wojcik, Oct 14, 2005
    #10
  11. Guest

    Thanks to all who responded to my fopen problem. Yoy are nice people.

    pete
     
    , Oct 17, 2005
    #11
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Nonee
    Replies:
    2
    Views:
    2,673
    Neredbojias
    Oct 25, 2005
  2. git_cs
    Replies:
    7
    Views:
    3,441
    Joe Wright
    Apr 30, 2004
  3. Gregory Graham

    Problem with fopen, linux, and RS-232, possibly

    Gregory Graham, Dec 8, 2004, in forum: C Programming
    Replies:
    3
    Views:
    456
    Gordon Burditt
    Dec 9, 2004
  4. Problem with fopen

    , Jan 29, 2006, in forum: C Programming
    Replies:
    3
    Views:
    362
    Roberto Waltman
    Jan 29, 2006
  5. Michel Rouzic
    Replies:
    4
    Views:
    1,842
    Michel Rouzic
    Apr 28, 2008
Loading...

Share This Page