fclose(0)

Re: fclose(0)

Bartc wrote:

"Eric Sosman" <esosman@ieee-dot-org.invalidwrot e in message
news:XImdnTItnK X_4I7VnZ2dnUVZ_ quhnZ2d@comcast .com...

>Bartc wrote:

>>"Richard Heathfield" <rjh@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.

The Committee's mandate was not to invent a new programming
language from whole cloth, but to codify existing practice insofar
as practical.

In the Rationale, the Committee laid out the principles that
it tried to apply when making decisions about the language. One
of these was "Keep the spirit of C," and the very first point in
the short list of facets that constitute that spirit is "Trust
the programmer." As Richard Heathfield pointed out earlier, trust
is not a one-sided relationship; the trusted party bears a burden
arising from the fact of being trusted.

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.

The good idea is not to pass a null pointer in the first place.
If you want a hand-holding language (and there's no shame in wanting
such a thing), you can find plenty of them.

--
Eric Sosman
esosman@ieee-dot-org.invalid

Re: fclose(0)

Richard Heathfield wrote:

Joe Wright said:
>

>Richard Heathfield wrote:

>
<snip>
>

>>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***.
>>>

>I'm not sure it's invalid. Consider..
>>
> FILE *fp = fopen("file", "r");
>>
>which fails for some reason. Later in the program we do..
>>
> int stat = fclose(fp);

>
If fp is a null pointer, the argument *is* invalid, because fclose requires
fp to be a pointer to a stream that is associated with a file. A null
pointer doesn't qualify, since it is guaranteed not to point to any
object.
>

It's a pity that case isn't specified in the way malloc/free is.

It is always safe to call free with the result of malloc, so it would be
consistent to always be a able to call any resource freeing function
with the result of its corresponding allocation function.

--
Ian Collins.

Re: fclose(0)

Joe Wright said:

Richard Heathfield wrote:

<snip>

>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***.
>>

I'm not sure it's invalid. Consider..
>
FILE *fp = fopen("file", "r");
>
which fails for some reason. Later in the program we do..
>
int stat = fclose(fp);

If fp is a null pointer, the argument *is* invalid, because fclose requires
fp to be a pointer to a stream that is associated with a file. A null
pointer doesn't qualify, since it is guaranteed not to point to any
object.

The fclose finds that fp does not point to an open file and returns EOF.

That is one legitimate outcome of undefined behaviour, yes. As you know,
there are plenty of others.

No crash, no problem.

I'm not sure I agree about the "no problem" part.

--
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

Re: fclose(0)

Richard Heathfield wrote:

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***.
>

I'm not sure it's invalid. Consider..

FILE *fp = fopen("file", "r");

which fails for some reason. Later in the program we do..

int stat = fclose(fp);

The fclose finds that fp does not point to an open file and returns EOF.

No crash, no problem.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

Re: fclose(0)

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

Re: fclose(0)


"Eric Sosman" <esosman@ieee-dot-org.invalidwrot e in message
news:XImdnTItnK X_4I7VnZ2dnUVZ_ quhnZ2d@comcast .com...

Bartc wrote:

>"Richard Heathfield" <rjh@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

Re: fclose(0)

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. ------

Re: fclose(0)

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
esosman@ieee-dot-org.invalid

Re: fclose(0)

Bartc wrote:

"Richard Heathfield" <rjh@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
esosman@ieee-dot-org.invalid

Re: fclose(0)

"Bartc" <bc@freeuk.comw 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) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Re: fclose(0)

Bartc said:

>
"Richard Heathfield" <rjh@see.sig.in validwrote in message
news:dZCdnaOyg5 Rp247VnZ2dnUVZ8 uadnZ2d@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

Re: fclose(0)

"Bartc" <bc@freeuk.comw 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

Re: fclose(0)


"Antoninus Twink" <nospam@nospam. invalidwrote in message
news:slrng16njs .5i9.nospam@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

Re: fclose(0)

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.)

Re: fclose(0)

Bartc wrote:

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

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

There is no defined behavior for Undefined Behavior.




Brian