When fopen() fails

[Sathyaish]

If fopen fails, is there a way to know why?

[Christopher Benson-Manica]

Sathyaish <Vi************ ****@yahoo.com> spoke thus:

If fopen fails, is there a way to know why?

If by "fails" you mean "returns NULL", yes. The global variable errno
(found in <errno.h>) contains information about what went wrong; you
can use perror() to print that information as a readable string.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[Dave Vandervies]

In article <cj**********@c hessie.cirr.com >,
Christopher Benson-Manica <at***@nospam.c yberspace.org> wrote:

Sathyaish <Vi************ ****@yahoo.com> spoke thus:

If fopen fails, is there a way to know why?
If by "fails" you mean "returns NULL", yes. The global variable errno
(found in <errno.h>) contains information about what went wrong; you
can use perror() to print that information as a readable string.

If I'm not mistaken, fopen isn't required to set errno if it fails.
(Though most implementations that attempt to provide nonzero QoI do
arrange for it to be set usefully.)
dave

--
Dave Vandervies dj******@csclub .uwaterloo.caClaiming that ANSI C does not allow a weird author at the keyboard is wrong.

Thanks for the clarification. For a moment there I was afraid I'd have to find
other work. --Ben Pfaff and Michael M Rubenstein in comp.lang.c

[Ben Pfaff]

Vi************* ***@yahoo.com (Sathyaish) writes:

If fopen fails, is there a way to know why?

You can examine errno or look at the corresponding message
returned by strerror(). It's not guaranteed to work portably,
but reasonable implementations will provide a useful message.
--
A competent C programmer knows how to write C programs correctly,
a C expert knows enough to argue with Dan Pop, and a C expert
expert knows not to bother.

[Gordon Burditt]

>If fopen fails, is there a way to know why?

errno might (*MIGHT*) tell you why. Or it might not. fopen() is
not guaranteed to set errno, but in my opinion it is worth presenting
the information to the user anyway. You can turn the errno code into
a supposedly-human-readable message with strerror() or perror().

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

FILE *f;

f = fopen(name, "r");
if (f == NULL) {
perror(name);
exit(EXIT_FAILU RE);
}

This code might give you a message like:

foo.txt: Permission denied
or
foo.txt: too many open files

or it might give you a message like:

foo.txt: Not a typewriter
or
foo.txt: Error 0

In creating error messages, it's a good idea to include WHAT failed,
on WHAT object, and WHY. The above examples don't say "opening for
read", and they really should, especially if the program may do
other things, like opening files for write or deleting them. If
the object is a file, include it's name (assuming it's available -
the name of stdout or stdin probably isn't). perror() or strerror()
will give you some idea of the WHY, sometimes.

Gordon L. Burditt

[Eric Sosman]

Christopher Benson-Manica wrote:

Sathyaish <Vi************ ****@yahoo.com> spoke thus:

If fopen fails, is there a way to know why?

If by "fails" you mean "returns NULL", yes. The global variable errno
(found in <errno.h>) contains information about what went wrong; you
can use perror() to print that information as a readable string.

FYI, this is true of many C implementations but it
is *not* required by the Standard. Some people think
that's a reason not to use perror() after fopen() fails:
the error message may have nothing at all to do with the
failure and could be misleading. Others (myself among
them) take the optimistic view that the error message
might be helpful, and are accustomed to treating all such
messages with just a little suspicion. Some go so far
as to decorate the message with a disclaimer:

FILE *fptr = fopen(filename, mode);
if (fptr == NULL) {
fprintf (stderr, "Failed to open %s\n"
"The reason *may* have been %s\n",
filename, strerror(errno) );
...
}

Take your pick.

--
Er*********@sun .com

[S.Tobias]

Eric Sosman <er*********@su n.com> wrote:

FYI, this is true of many C implementations but it
is *not* required by the Standard. Some people think

[snip]

fread/fwrite are not required.
Same for fgetc/fputc/fgets/etc...
fsetpos/fgetpos are.
ftell is, but fseek is not.
Functions like fgetwc are required to set errno only
with specific value, but not otherwise. fgetws is not
required to set errno.

These are just a couple of examples. I wonder why we have to have
such a mess. Why couldn't the Standard require all functions that
interface with the system to always set errno, or to set it to
some EUNKNOWN value if error information is unavailable?
In some cases it's obvious the error information is available
and the function could set errno (eg. if ftell can set errno, I don't
see a reason why fseek couldn't; same for fgetwc/fgetws pair).

I tend to avoid perror() at all, if I don't really-really have to.

--
Stan Tobias
sed 's/[A-Z]//g' to email

[Christopher Benson-Manica]

Eric Sosman <er*********@su n.com> spoke thus:

FYI, this is true of many C implementations but it
is *not* required by the Standard.

Whoops... thanks for the heads up.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[Dan Pop]

In <cj**********@c hessie.cirr.com > Christopher Benson-Manica <at***@nospam.c yberspace.org> writes:

Sathyaish <Vi************ ****@yahoo.com> spoke thus:

If fopen fails, is there a way to know why?

If by "fails" you mean "returns NULL", yes. The global variable errno
(found in <errno.h>) contains information about what went wrong; you
can use perror() to print that information as a readable string.

Yes, but you must be careful about it. The correct scenario is:
reset errno, call fopen, if it fails and errno is non-null you can assume
that its value provide a clue about the failure of fopen and translate it
into a meaningful message (perror or strerror), otherwise you must report
a failure for an unknown reason.

In the case of fopen, errno is the only mechanism provided by the C
language to help the programmer to generate meaningful error messages that
could help the user to understand and correct the problem. It is a shame
that the C standard doesn't require it to work.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de
Currently looking for a job in the European Union

[Dave Vandervies]

In article <ck**********@s unnews.cern.ch> , Dan Pop <Da*****@cern.c h> wrote:

if it fails and errno is non-null

Shouldn't that be "nonzero"? ('Ts an integer value and not a pointer,
after all...)
dave

--
Dave Vandervies dj******@csclub .uwaterloo.ca
And don't worry about being shown up as less than perfect. We've recently
found out that Dan Pop may not be perfect. We're still working on Lawrence
Kirby. --Joe Wright in comp.lang.c