By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,492 Members | 1,199 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,492 IT Pros & Developers. It's quick & easy.

When fopen() fails

P: n/a
If fopen fails, is there a way to know why?
Nov 14 '05 #1
Share this Question
Share on Google+
28 Replies


P: n/a
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)cyberspace.org | don't, I need to know. Flames welcome.
Nov 14 '05 #2

P: n/a
In article <cj**********@chessie.cirr.com>,
Christopher Benson-Manica <at***@nospam.cyberspace.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
Nov 14 '05 #3

P: n/a
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.
Nov 14 '05 #4

P: n/a
>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_FAILURE);
}

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
Nov 14 '05 #5

P: n/a
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
Nov 14 '05 #6

P: n/a
Eric Sosman <er*********@sun.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
Nov 14 '05 #7

P: n/a
Eric Sosman <er*********@sun.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)cyberspace.org | don't, I need to know. Flames welcome.
Nov 14 '05 #8

P: n/a
In <cj**********@chessie.cirr.com> Christopher Benson-Manica <at***@nospam.cyberspace.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
Nov 14 '05 #9

P: n/a
In article <ck**********@sunnews.cern.ch>, Dan Pop <Da*****@cern.ch> 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
Nov 14 '05 #10

P: n/a
Dave Vandervies wrote:

In article <ck**********@sunnews.cern.ch>,
Dan Pop <Da*****@cern.ch> wrote:
if it fails and errno is non-null


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


"null" just means "zero".
"null pointer" is a pointer, "null character" is an integer.

--
pete
Nov 14 '05 #11

P: n/a
pete <pf*****@mindspring.com> wrote:
Dave Vandervies wrote:

In article <ck**********@sunnews.cern.ch>,
Dan Pop <Da*****@cern.ch> wrote:
if it fails and errno is non-null
Shouldn't that be "nonzero"? ('Ts an integer value and not a pointer,
after all...)


"null" just means "zero".


Null is more general than "zero", because...
"null pointer" is a pointer,
....exactly. A null pointer need not be zero in any way (as opposed to a
null pointer _constant_).
"null character" is an integer.


But, depending on whether you mean '\0', or char a which happens to be
null, not necessarily an int.

Richard
Nov 14 '05 #12

P: n/a
In <ck**********@rumours.uwaterloo.ca> dj******@csclub.uwaterloo.ca (Dave Vandervies) writes:
In article <ck**********@sunnews.cern.ch>, Dan Pop <Da*****@cern.ch> wrote:
if it fails and errno is non-null


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


Please elaborate on the semantic differences between "null" and "zero"
in the context of the value of errno.

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

P: n/a
Richard Bos wrote:

pete <pf*****@mindspring.com> wrote:
Dave Vandervies wrote:

In article <ck**********@sunnews.cern.ch>,
Dan Pop <Da*****@cern.ch> wrote:

> if it fails and errno is non-null

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


"null" just means "zero".


Null is more general than "zero", because...
"null pointer" is a pointer,


...exactly. A null pointer need not be zero in any way
(as opposed to a null pointer _constant_).


A null pointer will compare equal to zero, that's one way.
"null character" is an integer.


But, depending on whether you mean '\0', or char a which happens to be
null, not necessarily an int.


I meant "integer", as in "integer type".

--
pete
Nov 14 '05 #14

P: n/a
Da*****@cern.ch (Dan Pop) writes:
In <ck**********@rumours.uwaterloo.ca> dj******@csclub.uwaterloo.ca
(Dave Vandervies) writes:
In article <ck**********@sunnews.cern.ch>, Dan Pop <Da*****@cern.ch> wrote:
if it fails and errno is non-null


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


Please elaborate on the semantic differences between "null" and "zero"
in the context of the value of errno.


There are no semantic differences, but "zero" would be clearer. The
word "null" is commonly used to refer to certain pointer values (NULL)
and character values ((char)'\0'), but rarely used to refer to a zero
integer value. The phrase "errno is non-null" isn't incorrect, it's
just an odd way of putting it. It's really not a big deal.

--
Keith Thompson (The_Other_Keith) ks***@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.
Nov 14 '05 #15

P: n/a
Dan Pop <Da*****@cern.ch> wrote:
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.


I don't quite understand it. What is the purpose of setting errno to
zero before function call? If a function sets errno on error, it will
do so - doesn't matter what the previous value was.

--
Stan Tobias
sed 's/[A-Z]//g' to email
Nov 14 '05 #16

P: n/a
In article <2s*************@uni-berlin.de>,
S.Tobias <sN*******@amu.edu.pl> wrote:
I don't quite understand it. What is the purpose of setting errno to
zero before function call? If a function sets errno on error, it will
do so - doesn't matter what the previous value was.


But functions doesn't clear errno on non-error, so you need to clear
it to be sure you are not seeing the some earlier (presumably
already-dealt-with) error.

-- Richard
Nov 14 '05 #17

P: n/a
In article <2s*************@uni-berlin.de>,
"S.Tobias" <sN*******@amu.edu.pl> wrote:
Dan Pop <Da*****@cern.ch> wrote:
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.


I don't quite understand it. What is the purpose of setting errno to
zero before function call? If a function sets errno on error, it will
do so - doesn't matter what the previous value was.


But fopen() is not required to set errno every time it returns NULL. So
there is no way to reliably differentiate "failed and set errno" and
"failed and did not set errno" without resetting errno before the call.

This is quite similar to the problem of reliably getting an error return
from strtoul().

Cheers,
- jonathan
Nov 14 '05 #18

P: n/a
Jonathan Adams <jw*****@gmail.com> wrote:
In article <2s*************@uni-berlin.de>,
"S.Tobias" <sN*******@amu.edu.pl> wrote:
I don't quite understand it. What is the purpose of setting errno to
zero before function call? If a function sets errno on error, it will
do so - doesn't matter what the previous value was.

But fopen() is not required to set errno every time it returns NULL.


Ah, thanks! I think I see what I was missing.

If a function does not communicate an error via errno, it is allowed
to set errno to any value it wants (except zero).
If a function communicates errors though errno, it is required either
to set errno to an error value, or to leave errno with the same value
as before the call.

Please correct me if that's not right.

--
Stan Tobias
sed 's/[A-Z]//g' to email
Nov 14 '05 #19

P: n/a
S.Tobias wrote:
Jonathan Adams <jw*****@gmail.com> wrote:
In article <2s*************@uni-berlin.de>,
"S.Tobias" <sN*******@amu.edu.pl> wrote:


I don't quite understand it. What is the purpose of setting errno to
zero before function call? If a function sets errno on error, it will
do so - doesn't matter what the previous value was.


But fopen() is not required to set errno every time it returns NULL.

Ah, thanks! I think I see what I was missing.

If a function does not communicate an error via errno, it is allowed
to set errno to any value it wants (except zero).
If a function communicates errors though errno, it is required either
to set errno to an error value, or to leave errno with the same value
as before the call.

Please correct me if that's not right.


That's *almost* right. If an errno-setting function
succeeds, it may set errno to any non-zero value that it
pleases; it need not leave errno unchanged. When the
function returns its success indication it means "errno
is irrelevant," not "errno is undisturbed."

See Question 12.24 in the comp.lang.c Frequently Asked
Questions (FAQ) list

http://www.eskimo.com/~scs/C-faq/top.html

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

Nov 14 '05 #20

P: n/a
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
Da*****@cern.ch (Dan Pop) writes:
In <ck**********@rumours.uwaterloo.ca> dj******@csclub.uwaterloo.ca
(Dave Vandervies) writes:
In article <ck**********@sunnews.cern.ch>, Dan Pop <Da*****@cern.ch> wrote:

if it fails and errno is non-null

Shouldn't that be "nonzero"? ('Ts an integer value and not a pointer,
after all...)
Please elaborate on the semantic differences between "null" and "zero"
in the context of the value of errno.


There are no semantic differences, but "zero" would be clearer.


If there are no semantic differences, both are equally clear, considering
that both "null" and "zero" are common English words.
The
word "null" is commonly used to refer to certain pointer values (NULL)
and character values ((char)'\0'), but rarely used to refer to a zero
integer value.
"Null pointer", "null pointer constant" and "null character" are all
concepts defined by the C standard. They don't monopolise the usage of
the word "null" any more than "floating point" and "decimal point"
monopolise the usage of the word "point".
The phrase "errno is non-null" isn't incorrect, it's
just an odd way of putting it.
If I saw anything odd about it, I wouldn't have used it in the first
place. And this is not an English language issue (and myself being a
non-native English speaker); it's exactly the same in my native language
(except that "null" is spelled with a single ell :-)
It's really not a big deal.


An excellent reason for NOT ignoring it in c.l.c ;-)

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

P: n/a
In <2s*************@uni-berlin.de> "S.Tobias" <sN*******@amu.edu.pl> writes:
If a function does not communicate an error via errno, it is allowed
to set errno to any value it wants (except zero).
If a function communicates errors though errno, it is required either
to set errno to an error value, or to leave errno with the same value
as before the call.

Please correct me if that's not right.


Use the following simple model: the value of errno may be meaningful
after a *failed* function call only if it was reset before the call
and it is non-zero after the (failed) function call.

The standard guarantees that for a restricted set of library functions,
but a good implementation should use errno whenever there is no other
way of telling why a function failed. E.g. if getc fails, you can use
ferror() and feof() to distinguish between an I/O error condition and an
end of file condition, but when fopen fails, *only* errno can provide a
clue.

The value of errno is useless in any other scenario (all we know about it
is that it is guaranteed to be 0 when the program execution begins and
that no standard library function resets it).

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

P: n/a
Dan Pop <Da*****@cern.ch> wrote:
In <2s*************@uni-berlin.de> "S.Tobias" <sN*******@amu.edu.pl> writes:
If a function does not communicate an error via errno, it is allowed
to set errno to any value it wants (except zero).
If a function communicates errors though errno, it is required either
to set errno to an error value, or to leave errno with the same value
as before the call.

Please correct me if that's not right.


[Thanks to Eric Sosman - while writing the above I was thinking in context
of a failed call, but of course I wasn't clear about it. Anyway good
you added more explanation.]
Use the following simple model: the value of errno may be meaningful
after a *failed* function call only if it was reset before the call
and it is non-zero after the (failed) function call.
....and provided that the function is actually errno-setting; otherwise
it's meaningless again, which makes portable programming very hard.
I have very bad feelings about errno:
errno = 0;
if (!fopen(..))
#if fopen_is_errno_setting
perror("fopen()");
#else
fputs("fopen() failed\n", stderr);
#endif
The standard guarantees that for a restricted set of library functions,
but a good implementation should use errno whenever there is no other
way of telling why a function failed. E.g. if getc fails, you can use
ferror() and feof() to distinguish between an I/O error condition and an
end of file condition, but when fopen fails, *only* errno can provide a
clue.
I think it's not entirely correct (non-)analogy. fopen() always returns
NULL when it fails, so we do know an error situation has arisen, but
errno can give us more information on the *nature* of the error. getc()
returns NULL on error or on end-of-file (which I don't consider an error
condition, but tastes may vary), and ferror() can distinguish between
the two. But here we don't have any information as to the nature of
the error, because getc() does not set errno.
The value of errno is useless in any other scenario (all we know about it
is that it is guaranteed to be 0 when the program execution begins and
that no standard library function resets it).


Is it a good idea for a user function to communicate its own errors
through errno? Could additional E.. macros from errno.h have negative
values (the Std doesn't seem to restrict this, but I haven't met a
system where this would be true)?

--
Stan Tobias
sed 's/[A-Z]//g' to email
Nov 14 '05 #23

P: n/a
S.Tobias wrote:

Is it a good idea for a user function to communicate its own errors
through errno? Could additional E.. macros from errno.h have negative
values (the Std doesn't seem to restrict this, but I haven't met a
system where this would be true)?


Not a good idea, I think. The immediate practical
difficulty is in getting perror() and strerror() to
recognize the application-defined values; the Standard
provides no way to do this.

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

Nov 14 '05 #24

P: n/a
pete <pf*****@mindspring.com> wrote:
Richard Bos wrote:

pete <pf*****@mindspring.com> wrote:
"null pointer" is a pointer,


...exactly. A null pointer need not be zero in any way
(as opposed to a null pointer _constant_).


A null pointer will compare equal to zero, that's one way.


No, it won't. It will compare to a _source_ zero, because that's also a
null pointer constant, but that's a special property of the null pointer
constant, _not_ of the null pointer object. It need not, for example,
compare equal to an integer object with value zero.
"null character" is an integer.


But, depending on whether you mean '\0', or char a which happens to be
null, not necessarily an int.


I meant "integer", as in "integer type".


I realised that, I just thought I'd point it out explicitly for the
lurkers.

Richard
Nov 14 '05 #25

P: n/a
In <2s*************@uni-berlin.de> "S.Tobias" <sN*******@amu.edu.pl> writes:
Dan Pop <Da*****@cern.ch> wrote:
Use the following simple model: the value of errno may be meaningful
after a *failed* function call only if it was reset before the call
and it is non-zero after the (failed) function call.


...and provided that the function is actually errno-setting; otherwise
it's meaningless again, which makes portable programming very hard.
I have very bad feelings about errno:
errno = 0;
if (!fopen(..))
#if fopen_is_errno_setting
perror("fopen()");
#else
fputs("fopen() failed\n", stderr);
#endif


It's a quality of implementation issue. A good implementation of a
standard library function either sets errno to a meaningful value
upon failure or preserves its value. So, my approach is likely to work
quite well, even if the standard doesn't guarantee it.

If you don't want to rely on it, you're restricted to the two errno
values of C89 or three errno values of C99 and you won't be able to tell
the user why fopen() failed, because you have no portable way of telling
whether fopen sets errno to meaningful values or not.
The standard guarantees that for a restricted set of library functions,
but a good implementation should use errno whenever there is no other
way of telling why a function failed. E.g. if getc fails, you can use
ferror() and feof() to distinguish between an I/O error condition and an
end of file condition, but when fopen fails, *only* errno can provide a
clue.


I think it's not entirely correct (non-)analogy. fopen() always returns
NULL when it fails, so we do know an error situation has arisen, but
errno can give us more information on the *nature* of the error. getc()
returns NULL on error or on end-of-file (which I don't consider an error
condition, but tastes may vary), and ferror() can distinguish between
the two. But here we don't have any information as to the nature of
the error, because getc() does not set errno.


Huh? There are exactly two things that can go wrong: an I/O error and
an eof condition. Neither the programmer nor the user needs to know more
than that.
The value of errno is useless in any other scenario (all we know about it
is that it is guaranteed to be 0 when the program execution begins and
that no standard library function resets it).


Is it a good idea for a user function to communicate its own errors
through errno? Could additional E.. macros from errno.h have negative
values (the Std doesn't seem to restrict this, but I haven't met a
system where this would be true)?


Macros that begin with E and a digit or E and an uppercase letter are in
the implementation name space and can't be defined by portable programs.

And errno itself, without perror and strerror is not of much use to the
application programmer. For other libraries, it's much safer to
replace errno by lib_errno and provide lib_perror and lib_strerror.

The issue was discussed, at great length, 1 year or 18 months ago, in the
context of the comp.lang.c library project. The project died when its
main advocates realised that they can't do as much as they intended
within the constraints of the C standard (mainly, they felt that a library
that is not thread-safe is not of much use to them and thread-safety
cannot be achieved in portable C code).

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

P: n/a
Dan Pop <Da*****@cern.ch> wrote:
In <2s*************@uni-berlin.de> "S.Tobias" <sN*******@amu.edu.pl> writes:
[snip]
I have very bad feelings about errno:
errno = 0;
if (!fopen(..))
#if fopen_is_errno_setting
perror("fopen()");
#else
fputs("fopen() failed\n", stderr);
#endif
[snip] If you don't want to rely on it, you're restricted to the two errno
values of C89 or three errno values of C99 and you won't be able to tell
the user why fopen() failed, because you have no portable way of telling
whether fopen sets errno to meaningful values or not.
I only think that errno handling is badly designed by the Standard.
The Standard allows to introduce extensions here, but in a very unfriendly
way. In theory, on every new implementation I want to port to, I have
to check *each* function whether it is errno-setting, otherwise I might
get unrelated error messages. OTOH nothing vital should depend on perror()
and errno (in general). I consider it more like a debugging feature.

way of telling why a function failed. E.g. if getc fails, you can use
ferror() and feof() to distinguish between an I/O error condition and an
end of file condition, but when fopen fails, *only* errno can provide a ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ clue.
^^^^
Failing getc() (ferror() set) doesn't give any more or less clue than
a NULL from fopen(). errno could be/is auxiliary feature for both.
errno can give us more information on the *nature* of the error. getc()
returns NULL on error or on end-of-file (which I don't consider an error
condition, but tastes may vary), and ferror() can distinguish between
the two. But here we don't have any information as to the nature of
the error, because getc() does not set errno. Huh? There are exactly two things that can go wrong: an I/O error and
an eof condition. Neither the programmer nor the user needs to know more
than that.


You can apply similar argument to fopen().

Could additional E.. macros from errno.h have negative
values (the Std doesn't seem to restrict this, but I haven't met a
system where this would be true)?


In the past I worked a little with Berkeley DB. All functions returned
error status (zero for no error). IIRC positive values were system
errors (from errno.h), low negative values were reserved for the library
errors (it supplied its own strerror()), and high negative numbers
(nearer zero) were reserved for user errors. I have started to
wonder how "safe" is the assumption that with this scheme we won't
step onto an implementation's E.. values. (I have checked - even
SUS3 doesn't (explicitly) require all E.. numbers be positive).
--
Stan Tobias
sed 's/[A-Z]//g' to email
Nov 14 '05 #27

P: n/a
In <2t*************@uni-berlin.de> "S.Tobias" <sN*******@amu.edu.pl> writes:
Dan Pop <Da*****@cern.ch> wrote:
[snip]
>> way of telling why a function failed. E.g. if getc fails, you can use
>> ferror() and feof() to distinguish between an I/O error condition and an
>> end of file condition, but when fopen fails, *only* errno can provide a ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> clue. ^^^^
Failing getc() (ferror() set) doesn't give any more or less clue than
a NULL from fopen().
Nonsense. ferror() set after a failed getc call means an I/O error
occurred, while an I/O error is only *one* of the many reasons fopen
can fail.
errno could be/is auxiliary feature for both.


The average user couldn't care less about the exact nature of the I/O
error. When such information is needed, there are other, *much*
better ways of retrieving it (system logging facilities). What errno
setting should correspond to "bad CRC on sector 1234233 on disk 08:01"?
>errno can give us more information on the *nature* of the error. getc()
>returns NULL on error or on end-of-file (which I don't consider an error
>condition, but tastes may vary), and ferror() can distinguish between
>the two. But here we don't have any information as to the nature of
>the error, because getc() does not set errno.

Huh? There are exactly two things that can go wrong: an I/O error and
an eof condition. Neither the programmer nor the user needs to know more
than that.


You can apply similar argument to fopen().


Nope: an I/O error is only one of the many reasons fopen can fail.
No similarity in sight.

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

P: n/a
Dan Pop <Da*****@cern.ch> wrote:
In <2t*************@uni-berlin.de> "S.Tobias" <sN*******@amu.edu.pl> writes:
Failing getc() (ferror() set) doesn't give any more or less clue than
a NULL from fopen(). Nonsense. ferror() set after a failed getc call means an I/O error
occurred, while an I/O error is only *one* of the many reasons fopen
can fail.
All right. I was paying more attention to the general idea rather than
to the particular function I was talking about. Perhaps fputc() is
more amenable to the discussion. Most previous arguments apply to it,
except it does not set feof() of course.

GNU man pages don't mention that fputc() sets errno, but SUS3 does.
Looking at the list of errors, I think that differentiating between
EIO, EFBIG and ENOSPC might be important to the user.

Looking at the analogous list for fgetc(), there are less errors
that a user might be interested in, but it definitely shows that
I/O errors are *not* the only reasons for fgetc() failure (ENOMEM,
EINTR, EBADF).

I would see nothing wrong if on some implementaton getc() could fail
and set errno to ETEA, where strerror(ETEA) returned:
"it's after 5pm, CPU is having tea-time, be back in 20 minutes"

[snip]
Huh? There are exactly two things that can go wrong: an I/O error and
an eof condition. Neither the programmer nor the user needs to know more
than that.


You can apply similar argument to fopen().

Nope: an I/O error is only one of the many reasons fopen can fail.
No similarity in sight.


I agree that errno from fopen() is much more valuable and informative
to the user. I can do without, so I usually don't care about it.
I really wouldn't like to spark a long discussion on this. My remark
was just meant to be about analogies on a more abstract-like level
rather than practical.

--
Stan Tobias
sed 's/[A-Z]//g' to email
Nov 14 '05 #29

This discussion thread is closed

Replies have been disabled for this discussion.