NULL returned by fopen - where is a list of what's causing the error?

[Keith Thompson]

On Tue, 31 Jan 2006 07:54:20 -0500, Eric Sosman


where is the nonsense, is it because i don't print the file name in
case fopen fail? i don't have "faq" list

If you have a web browser and an Internet connection, you can see the
FAQ at

<http://www.c-faq.com>

It works well even with a text-based browser such as Lynx.

If you can do ftp but not http, a gzipped plain ASCII copy is
available at

<ftp://ftp.eskimo.com/u/s/scs/C-faq/faq.gz>

If you can't handle either of those, contact me directly with a valid
e-mail address and I'll be glad to send you a plain text copy by
e-mail. Let me know whether you want plain ASCII text or gzipped
text, and whether you can handle e-mail attachments (if not, I'll
include the plain text version in-line in the message). Since you use
a fake e-mail address, I promise not to divulge your e-mail address to
anyone unless truly extraordinary and unlikely circumstances require
me to do so.

 

[Mark B]

Not necessarily. The standard doesn't say that fopen() sets errno, so
it's possible for fopen() to fail but for errno to remain 0.

It's also possible that errno could be set when the call actually succeeded.

7.5 #3 (draft)
.... The value of errno may be set to nonzero by a library function call
whether or not there is an error, provided the use of errno is not
documented
in the description of the function in this International Standard.

Seems the only a library function can NOT do is explicitly set it to 0.

Mark

 

[Default User]

If you have a web browser and an Internet connection, you can see the
FAQ at

This clown (RSoIsCaIrLiIoA, not Keith) shows every now and then to
troll the group. I'd recommend a swift killfile from all.



Brian

 

[Keith Thompson]

It's also possible that errno could be set when the call actually succeeded.

[...]

Right, and the code already allows for that possibility by not
referring to errno unless pFile == NULL.

 

[Mark B]

It's also possible that errno could be set when the call actually
succeeded.

[...]

Right, and the code already allows for that possibility by not
referring to errno unless pFile == NULL.

The code also assumes that if errno is set after failure that the
value will be meaningful... that is not guaranteed by the standard.
The only guarantee is that fopen() will not set errno = 0;

 

[Keith Thompson]

RSoIsCaIrLiIoA wrote:

ferrad wrote On 01/20/06 11:35,:

On many systems, the `errno' pseudo-variable may
give additional information about a failure. Try
something like
errno=0;

This is a possible improvement in that it might help
avoid nonsense messages from implementations that don't
set errno when fopen() fails.

Yes.

pFile = fopen(cFileName, "a+");
if (pFile == NULL) {
perror (cFileName);
if(errno) perror(cFileName)

This, however, is nonsense. See Question 20.4 in
the comp.lang.c Frequently Asked Questions (FAQ) list
at http://c-faq.com/ .

Not necessarily. The standard doesn't say that fopen() sets errno, so
it's possible for fopen() to fail but for errno to remain 0.

It's also possible that errno could be set when the call actually
succeeded.

[...]

Right, and the code already allows for that possibility by not
referring to errno unless pFile == NULL.

The code also assumes that if errno is set after failure that the
value will be meaningful... that is not guaranteed by the standard.
The only guarantee is that fopen() will not set errno = 0;

In my opinion, it only assumes that if errno is set to a non-zero
value after failure, then that value is worth showing to the user.
(I have no idea what the author might have assumed.)

 

[Joe Wright]

RSoIsCaIrLiIoA wrote:



ferrad wrote On 01/20/06 11:35,:

On many systems, the `errno' pseudo-variable may
give additional information about a failure. Try
something like

errno=0;

This is a possible improvement in that it might help
avoid nonsense messages from implementations that don't
set errno when fopen() fails.

Yes.


pFile = fopen(cFileName, "a+");
if (pFile == NULL) {
perror (cFileName);

if(errno) perror(cFileName)

This, however, is nonsense. See Question 20.4 in
the comp.lang.c Frequently Asked Questions (FAQ) list
at http://c-faq.com/ .

Not necessarily. The standard doesn't say that fopen() sets errno, so
it's possible for fopen() to fail but for errno to remain 0.

It's also possible that errno could be set when the call actually
succeeded.

[...]

Right, and the code already allows for that possibility by not
referring to errno unless pFile == NULL.

The code also assumes that if errno is set after failure that the
value will be meaningful... that is not guaranteed by the standard.
The only guarantee is that fopen() will not set errno = 0;

In my opinion, it only assumes that if errno is set to a non-zero
value after failure, then that value is worth showing to the user.
(I have no idea what the author might have assumed.)

Don't you love it. The library can't set errno to 0. I can be set to any
positive number so long as the setting is not described in the Standard.
So puts() can set errno to 9 if it likes, as long as it doesn't tell
anybody. If you would document that, you can't do it.

Careful, reading the Standard too hard can make your head hurt.

 

[Jordan Abel]

Don't you love it. The library can't set errno to 0. I can be set to any
positive number so long as the setting is not described in the Standard.
So puts() can set errno to 9 if it likes, as long as it doesn't tell
anybody. If you would document that, you can't do it.

Eh? Your documentation isn't the standard - therefore you documenting it
doesn't make it "described in the standard" - the text you're referring
to just means that you can't do it if the standard specifically tells
you not to, or specifically says what it's set to.

 

[Joe Wright]

Eh? Your documentation isn't the standard - therefore you documenting it
doesn't make it "described in the standard" - the text you're referring
to just means that you can't do it if the standard specifically tells
you not to, or specifically says what it's set to.

[#3] The value of errno is zero at program startup, but is
never set to zero by any library function.159) The value of
errno may be set to nonzero by a library function call
whether or not there is an error, provided the use of errno
is not documented in the description of the function in this
International Standard.

Ok, I see it now. Thanks.

 

[RSoIsCaIrLiIoA]

If you have a web browser and an Internet connection, you can see the
FAQ at

<http://www.c-faq.com>

It works well even with a text-based browser such as Lynx.

If you can do ftp but not http, a gzipped plain ASCII copy is
available at

<ftp://ftp.eskimo.com/u/s/scs/C-faq/faq.gz>

If you can't handle either of those, contact me directly with a valid
e-mail address and I'll be glad to send you a plain text copy by
e-mail. Let me know whether you want plain ASCII text or gzipped
text, and whether you can handle e-mail attachments (if not, I'll
include the plain text version in-line in the message). Since you use
a fake e-mail address, I promise not to divulge your e-mail address to
anyone unless truly extraordinary and unlikely circumstances require
me to do so.

am i for you the kind of person that has need of something else than
K&R book? then "Question 20.4" is not in the faq posted here in this
news-group

 

[Vladimir S. Oka]

am i for you the kind of person that has need of something else than
K&R book? then "Question 20.4" is not in the faq posted here in this
news-group

Actually, no. You'd really want at least K&R2 (i.e. Second Edition), but
getting C standard itself is even better. I don't have URLs to it right
now (you can get last public draft of C90 and current public draft of
C99 for free; searching this group for links may help).

Keith also pointed you to www.c-faq.com where you can find 20.4 as well.
For your convenience, here's the direct link to 20.4:

http://www.c-faq.com/misc/errno.html

Cheers

Vladimir

 

[Keith Thompson]

am i for you the kind of person that has need of something else than
K&R book? then "Question 20.4" is not in the faq posted here in this
news-group

According to groups.google.com, the full FAQ list has not been posted
to comp.lang.c since Nov 1, 2004. An abridged FAQ list was posted on
Nov 1, 2005 and again on Feb 1, 2006; the abridged list doesn't
include question 20.4. The most recently posted full version doesn't
include question 20.4 either.

I've tended to ignore the posted FAQ, since the web version is so much
easier (for me) to access; perhaps that's why Steve hasn't been
posting it as regularly. It was also updated recently, and question
20.4 was part of the update.

Here's question 20.4 from the current web version:

Q: What's the right way to use errno?

A: In general, you should detect errors by checking return values,
and use errno only to distinguish among the various causes of an
error, such as ``File not found'' or ``Permission
denied''. (Typically, you use perror or strerror to print these
discriminating error messages.) It's only necessary to detect
errors with errno when a function does not have a unique,
unambiguous, out-of-band error return (i.e. because all of its
possible return values are valid; one example is atoi). In these
cases (and in these cases only; check the documentation to be sure
whether a function allows this), you can detect errors by setting
errno to 0, calling the function, then testing errno. (Setting
errno to 0 first is important, as no library function ever does
that for you.)

To make error messages useful, they should include all relevant
information. Besides the strerror text derived from errno, it may
also be appropriate to print the name of the program, the
operation which failed (preferably in terms which will be
meaningful to the user), the name of the file for which the
operation failed, and, if some input file (script or source file)
is being read, the name and current line number of that file.

See also question 12.24.

References: ISO Sec. 7.1.4, Sec. 7.9.10.4, Sec. 7.11.6.2
CT&P Sec. 5.4 p. 73
PCS Sec. 11 p. 168, Sec. 14 p. 254

My offer stands: if you're really unable to read the web version, I
can send you a copy. See my previous article for details. If you
have any kind of web access at all, it will be easier for you either
to access the web version directly, or to download another version
yourself from c-faq.com, but I don't know your situation.

I make this offer because I made it before, and I don't want to take
it back. However, you have recently been disrupting this newsgroup by
repeatedly posting huge chunks of assembly language, and you have
continued to do so after being asked to stop. You've engaged in
similar trollish behavior in the past. If you don't stop, this will
be my very last offer to help you. This offer expires permanently in
one week.

 

[Steve Summit]

According to groups.google.com, the full FAQ list has not been posted
to comp.lang.c since Nov 1, 2004...
I've tended to ignore the posted FAQ, since the web version is so much
easier (for me) to access; perhaps that's why Steve hasn't been
posting it as regularly.

No, the script which posts the FAQ list is totally automated and
hasn't changed in so long that I have very little memory of how
it even works. The full FAQ list does indeed get posted every
month, but the fact that it's not showing up on google groups
suggests a propagation problem somewhere. Dang.

It would appear to be getting lost somewhere along the path
eskimo.com -> newsfeeds.com -> newshosting.com -> giganews.com ->
google.com. I'll write to the various postmasters along that
path and see if I can get any of them to look into it.

 

[Keith Thompson]

No, the script which posts the FAQ list is totally automated and
hasn't changed in so long that I have very little memory of how
it even works. The full FAQ list does indeed get posted every
month, but the fact that it's not showing up on google groups
suggests a propagation problem somewhere. Dang.

It would appear to be getting lost somewhere along the path
eskimo.com -> newsfeeds.com -> newshosting.com -> giganews.com ->
google.com. I'll write to the various postmasters along that
path and see if I can get any of them to look into it.

FWIW, news.ucsd.edu currently has two copies of the full FAQ, dated
2005-08-01 and 2005-10-01, and three copies of the abridged FAQ, dated
2005-08-15, 2005-09-15, and 2005-10-01. (It's not the news server I
usually use, but it has a much longer retention time.)

 

[RSoIsCaIrLiIoA]

am i for you the kind of person that has need of something else than
K&R book? then "Question 20.4" is not in the faq posted here in this
news-group

[...]

Here's question 20.4 from the current web version:

Q: What's the right way to use errno?

A: In general, you should detect errors by checking return values,
and use errno only to distinguish among the various causes of an
error, such as ``File not found'' or ``Permission
denied''. (Typically, you use perror or strerror to print these
discriminating error messages.) It's only necessary to detect
errors with errno when a function does not have a unique,
unambiguous, out-of-band error return (i.e. because all of its
possible return values are valid; one example is atoi). In these
cases (and in these cases only; check the documentation to be sure
whether a function allows this), you can detect errors by setting
errno to 0, calling the function, then testing errno. (Setting
errno to 0 first is important, as no library function ever does
that for you.)

so it seems i have right

To make error messages useful, they should include all relevant
information. Besides the strerror text derived from errno, it may
also be appropriate to print the name of the program, the
operation which failed (preferably in terms which will be
meaningful to the user), the name of the file for which the
operation failed, and, if some input file (script or source file)
is being read, the name and current line number of that file.

See also question 12.24.

References: ISO Sec. 7.1.4, Sec. 7.9.10.4, Sec. 7.11.6.2
CT&P Sec. 5.4 p. 73
PCS Sec. 11 p. 168, Sec. 14 p. 254

My offer stands: if you're really unable to read the web version,

i can read and copy a web version; anyway thank you

I
can send you a copy. See my previous article for details. If you
have any kind of web access at all, it will be easier for you either
to access the web version directly, or to download another version
yourself from c-faq.com, but I don't know your situation.

I make this offer because I made it before, and I don't want to take
it back. However, you have recently been disrupting this newsgroup by
repeatedly posting huge chunks of assembly language, and you have
continued to do so after being asked to stop.

if there is a little problem here, in this news-group, it could be the
OT questions that begin the treads; another problem could be that many
people give to NGs more importance than they really have.
i not think i'm a problem for this group because i generally don't
begin the treads nor i like to speak

You've engaged in
similar trollish behavior in the past. If you don't stop, this will
be my very last offer to help you. This offer expires permanently in
one week.

here i can be me
i'm in this way: this is what i'am. you can accept or not

 

[Mark McIntyre]

[...]

However, you have recently been disrupting this newsgroup by

repeatedly posting huge chunks of assembly language, and you have
continued to do so after being asked to stop.

i not think i'm a problem for this group because i generally don't
begin the treads nor i like to speak

I don't follow this logic. You didn't start the thread - fine - but
that doesn't mean you can now post offtopic and irrelevant responses.

i'm in this way: this is what i'am. you can accept or not

If what you are is a troll, then we accept that, killfile you and move
on.

If on the other hand you want useful help, you will need to fit in
with the group. You have six days.
Mark McIntyre

 

[Keith Thompson]

If what you are is a troll, then we accept that, killfile you and move
on.

If on the other hand you want useful help, you will need to fit in
with the group. You have six days.

To be clear, the one-week expiration referred *only* to my offer to
send RSoIsCaIrLiIoA a copy of the FAQ by e-mail. RSoIsCaIrLiIoA
replied: "i can read and copy a web version; anyway thank you", so
that's no longer relevant. At this point, there is no deadline as far
as I'm concerned. I intend to treat RSoIsCaIrLiIoA as a troll (i.e.,
ignore him/her except as necessary to correct any misinformation)
starting immediately; others will do as they see fit.

I see no point in continuing this discussion, but don't let that stop
you if you have something to add.

 

[Default User]

I intend to treat RSoIsCaIrLiIoA as a troll (i.e.,
ignore him/her except as necessary to correct any misinformation)
starting immediately; others will do as they see fit.

I see no point in continuing this discussion, but don't let that stop
you if you have something to add.

I'm not even sure why this is a matter for discussion. This isn't the
first time he's trolled the group, I plonked him long ago.



Brian

 

[Mark McIntyre]

To be clear, the one-week expiration referred *only* to my offer to
send RSoIsCaIrLiIoA a copy of the FAQ by e-mail.

My misunderstanding. Apologies.
Mark McIntyre

 

[Mark McIntyre]

I'm not even sure why this is a matter for discussion. This isn't the
first time he's trolled the group, I plonked him long ago.

Same here, though he escaped by changing ISP I think. I was giving him
the benefit of the doubt, I'm not sure I'll bother much longer.
Mark McIntyre