fopen problem

[pjlsr@netscape.com]

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("f ilename","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

[Robert Gamble]

Re: fopen problem

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

pjlsr@netscape. com wrote:[color=blue]
> 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("f ilename","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.[/color]

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

[Gordon Burditt]

Re: fopen problem

>It's close to twenty years since I used the C language and at that time[color=blue]
>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[/color]

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.
[color=blue]
>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.[/color]

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

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.
[color=blue]
>I think fopen is where the problem is because it is supposed to return
>a small positive integer.[/color]

fopen() returns a pointer, *NOT* a small positive integer. If it
returns NULL, it failed.
[color=blue]
>To me '0' is not a small positive integer.[/color]

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.
[color=blue]
>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?[/color]

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

[Keith Thompson]

Re: fopen problem

pjlsr@netscape. com writes:
[...][color=blue]
> 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.[/color]

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_Keit h) kst-u@mib.org <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.

[pjlsr@netscape.com]

Re: fopen problem



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

[Martin Ambuhl]

Re: fopen problem

pjlsr@netscape. com wrote:[color=blue]
> 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("f ilename","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.[/color]

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

[Martin Ambuhl]

Re: fopen problem

pjlsr@netscape. com wrote:[color=blue]
>
> 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
>[/color]
#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_FAILU RE);
}
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_FAILU RE);
}
fclose(fp);
return 0;
}

[Emmanuel Delahaye]

Re: fopen problem

pjlsr@netscape. com a écrit :[color=blue]
> 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("f ilename","r") is used to open the file which very[/color]

Try that :

infile=fopen(fi lename,"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]

Re: fopen problem

pjlsr@netscape. com a écrit :[color=blue]
> 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("f ilename","r") is used to open the file which very[/color]

Try that :

infile=fopen(fi lename,"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.

[Michael Wojcik]

Re: fopen problem


In article <lnzmpcu51f.fsf @nuthaus.mib.or g>, Keith Thompson <kst-u@mib.org> writes:[color=blue]
>
> <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>[/color]

<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 michael.wojcik@ microfocus.com

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

[pjlsr@netscape.com]

Re: fopen problem

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

pete