fclose(0)

[Bartc]

This short program:

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

int main(void) {
int status;

status=fclose(0 );

printf("fclose( 0) status: %d\n",status);

}

crashes on the first two implementations I tried. Then I tried DMC and that
gave the expected EOF status.

Given the emphasis on error-checking in this group, it seems astonishing
that a library function (executed at most once per file) cannot do this
elementary check on it's parameter.

(It's possible a zero FILE* handle is returned by fopen() but the file has
to be closed for other reasons before it can checked by the application.)

Was I unlucky or is it normal for C library functions to be so fragile?

-- Bart

[Antoninus Twink]

On 26 Apr 2008 at 15:06, Bartc wrote:

int status;

status=fclose(0 );

fclose takes a pointer argument, so this is the same as
status=fclose(N ULL);
which is obviously not a good idea.

[guess] Instead of fclose, did you mean close, which takes a file
descriptor as an argument? Are you wondering about whether it's OK to
close(0) (i.e. close the stdin stream)? If so, the answer is yes: it's
useful for piping data between parent and child processes. (You can use
dup() to bind the output of a pipe back to stdin.)

[Bartc]

"Antoninus Twink" <no****@nospam. invalidwrote in message
news:sl******** ***********@nos pam.invalid...

On 26 Apr 2008 at 15:06, Bartc wrote:

>int status;

status=fclose( 0);

fclose takes a pointer argument, so this is the same as
status=fclose(N ULL);
which is obviously not a good idea.

[guess] Instead of fclose, did you mean close, which takes a file
descriptor as an argument? Are you wondering about whether it's OK to
close(0) (i.e. close the stdin stream)? If so, the answer is yes: it's
useful for piping data between parent and child processes. (You can use
dup() to bind the output of a pipe back to stdin.)

No, it came up in something like:

f=fopen(...);
fclose(f);

where the fopen failed. I would just have expected fclose to do nothing
given a null file handle (as I tend to do in my own functions that use
handles).

No big deal, I already use wrappers and it's a one-line fix. Was just mildly
surprised that that one line isn't already there.

--
Bartc

[Ben Pfaff]

"Bartc" <[e-mail] rites:

status=fclose(0 );

This yields undefined behavior. Are you thinking of
fflush(NULL), which is well-defined?
--
"Given that computing power increases exponentially with time,
algorithms with exponential or better O-notations
are actually linear with a large constant."
--Mike Lee

[Richard Heathfield]

Bartc said:

>
"Richard Heathfield" <rj*@see.sig.in validwrote in message
news:dZ******** *************** *******@bt.com. ..

>Bartc said:

>>This short program:

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

int main(void) {
int status;

status=fclose (0);

printf("fclos e(0) status: %d\n",status);

}

crashes on the first two implementations I tried.

The Standard requires that you pass to fclose a pointer to a stream
object of type FILE. You did not do this. (0 doesn't point to any object
at all, let alone a stream object.) You broke the rules, so all bets are
off.

fopen() returns a FILE* value, which can include NULL. So it's argueable
that NULL (or (FILE*)NULL) is acceptable, type-wise, to fclose().

No, it isn't, because the Standard doesn't say so. The Standard says that,
if you call fclose, you must pass to it a pointer to a stream object of
type FILE that has a file associated with it. You didn't do this.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Keith Thompson]

"Bartc" <[e-mail] rites:
[...]

>On 26 Apr 2008 at 15:06, Bartc wrote:

>>int status;

status=fclose (0);

[...]

>
No, it came up in something like:

f=fopen(...);
fclose(f);

where the fopen failed. I would just have expected fclose to do nothing
given a null file handle (as I tend to do in my own functions that use
handles).

In that case, it's probably just as easy to avoid calling fclose if
the fopen failed than to call it. You have to test whether fopen
succeeded anyway; if it doesn't, you don't attempt to read any input
from the file, right? So you have to do something like this:

f = fopen(...);
if (f != NULL) {
fread(...);
fclose(...);
}
else {
/* Report that you couldn't open the file */
}

No big deal, I already use wrappers and it's a one-line fix. Was just mildly
surprised that that one line isn't already there.

Yeah, most standard libary functions don't check for invalid input.
free(NULL) is a rare exception.

Note that, in the case of fclose(), checking for a null pointer
argument would just handle one failure case. There are plenty of
other errors that can't reasonably be caught, such as calling fclose()
with an uninitialized pointer.

--
Keith Thompson (The_Other_Keit h) <ks***@mib.or g>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Eric Sosman]

Bartc wrote:

"Richard Heathfield" <rj*@see.sig.in validwrote

>>
The Standard requires that you pass to fclose a pointer to a stream object
of type FILE. You did not do this. (0 doesn't point to any object at all,
let alone a stream object.) You broke the rules, so all bets are off.

fopen() returns a FILE* value, which can include NULL. So it's argueable
that NULL (or (FILE*)NULL) is acceptable, type-wise, to fclose().

The type is acceptable, but the value is not. Would
you expect `fprintf (NULL, "Hello, world!\n");' to work?
How about `fprintf (NULL, NULL);'?

The relevant passage is Section 7.1.4 paragraph 1:

"Each of the following statements applies unless
explicitly stated otherwise [...]: If an argument to
a function has an invalid value (such as [...] a null
pointer, [...]) [...]the behavior is undefined. [...]"

--
Eric Sosman
es*****@ieee-dot-org.invalid

[Eric Sosman]

Bartc wrote:

[...]
What's wrong with fclose() doing something like: "ABORTING: Invalid handle
to fclose()".

It does! The spelling of the error message differs somewhat
implementation to implementation; on one I'm familiar with, the
message is spelled "SIGSEGV" ...

--
Eric Sosman
es*****@ieee-dot-org.invalid

[Lew Pitcher]

In comp.lang.c, Eric Sosman wrote:

Bartc wrote:

>[...]
What's wrong with fclose() doing something like: "ABORTING: Invalid
handle to fclose()".

It does! The spelling of the error message differs somewhat
implementation to implementation; on one I'm familiar with, the
message is spelled "SIGSEGV" ...

and I've seen that message, but spelled as "S0C4"
--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

[Bartc]

"Eric Sosman" <es*****@ieee-dot-org.invalidwrot e in message
news:XI******** *************** *******@comcast .com...

Bartc wrote:

>"Richard Heathfield" <rj*@see.sig.in validwrote

>>>
The Standard requires that you pass to fclose a pointer to a stream
object
of type FILE. You did not do this. (0 doesn't point to any object at
all,
let alone a stream object.) You broke the rules, so all bets are off.

The relevant passage is Section 7.1.4 paragraph 1:

"Each of the following statements applies unless
explicitly stated otherwise [...]: If an argument to
a function has an invalid value (such as [...] a null
pointer, [...]) [...]the behavior is undefined. [...]"

I suspect this was written when there were already many implementations that
behaved this way.

If this was the case then it would be better to admit it rather than
suggest, as a few people have, that crashing on passing a null pointer is
actually a good idea.

--
Bartc

[Richard Heathfield]

Bartc said:

<snip>

If this was the case then it would be better to admit it rather than
suggest, as a few people have, that crashing on passing a null pointer is
actually a good idea.

Crashing is not an idea - either good or bad. It is merely a consequence.

If a programmer is dense enough to break the contract between himself and
the implementation, he has no business complaining when something happens
that he doesn't like. If you don't want a crash or some other bad
consequence of passing an invalid argument (and neither do I), the answer
is simple: ***don't pass an invalid argument***.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999