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

[CBFalconer]

Bartc wrote:

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

Of course. fclose requires a non-NULL FILE* parameter.

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

No, because if fopen returns a NULL (not a zero) it means the file
has not opened.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.
** Posted from http://www.teranews.com **

[CBFalconer]

Ben Bacarisse wrote:

>

.... snip ...

>
It's normal. Have you tried strlen(0), strcpy(0, 0) or fopen(0, 0)?
Luck is another matter. In a way you were lucky that at least one
implementation flagged up the call (with a crash). If you'd used
one that just returns EOF (which is allowed), you'd have no warning
that the construct is not portable.

Sure you would. The EOF is not a normal return value. Something
failed.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home .att.net>
Try the download section.

** Posted from http://www.teranews.com **

[lawrence.jones]

Bartc <[e-mail] rote:

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

It *is* a good idea: it forces programmers to fix their defective code.

-Larry Jones

I don't NEED to compromise my principles, because they don't have
the slightest bearing on what happens to me anyway. -- Calvin

[Ian Collins]

CBFalconer wrote:

Chris Torek wrote:

>Eric Sosman <es*****@ieee-dot-org.invalidwrot e:

.... snip ...

>A burden and a benefit, simultaneously. :-)

>>The good idea is not to pass a null pointer in the first place.

And yet, if this is the case, why does free() accept NULL? The
same argument holds here, and -- historically speaking -- at the
time the C89 standard was being created, actual implementations
actually crashed if you called free(NULL). So the committee have
attempted to have it both ways: "We trust you (putting the burden
of checking for NULL first) when you call fclose(), but we do not
trust you (removing the burden of checking for NULL first) when
you call free()".

However fclose doesn't crash on receiving a NULL. It returns EOF.

Says who? The behaviour is undefined.

--
Ian Collins.

[Richard Heathfield]

la************@ siemens.com said:

Bartc <[e-mail] rote:

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

It *is* a good idea:

No, it's merely a useful consequence.

it forces programmers to fix their defective code.

If that were true, it would be a pity that it isn't guaranteed by the
Standard. But it isn't true, of course. Some programmers never even see
the crashes, let alone fix their causes. For example, I have a web browser
written by someone else, which crashes whenever I accidentally click on a
PDF link and then click "cancel" on the subsequent dialog asking if I want
to hand over my firstborn to Adobe. Clearly the programmer never bothered
to test this execution path, so he has /not/ been forced to fix his
defective code.

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

[Richard Heathfield]

CBFalconer said:

<snip>

However fclose doesn't crash on receiving a NULL. It returns EOF.

$ cat foo.c
#include <stdio.h>

int main(void)
{
fclose(NULL);
printf("Hello, world!\n");
return 0;
}

$ ./foo
Segmentation fault (core dumped)

Undefined behaviour need not have the same effect on my system as it does
on yours. I was under the impression that you already knew that.

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

[Ian Collins]

Richard Heathfield wrote:

la************@ siemens.com said:

>Bartc <[e-mail] rote:

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

It *is* a good idea:

No, it's merely a useful consequence.

>it forces programmers to fix their defective code.

If that were true, it would be a pity that it isn't guaranteed by the
Standard. But it isn't true, of course. Some programmers never even see
the crashes, let alone fix their causes. For example, I have a web browser
written by someone else, which crashes whenever I accidentally click on a
PDF link and then click "cancel" on the subsequent dialog asking if I want
to hand over my firstborn to Adobe. Clearly the programmer never bothered
to test this execution path, so he has /not/ been forced to fix his
defective code.

But he or she would if a paying customer filed a bug report. That is,
unless he or she works for a well known supplier of non-compliant browsers.

--
Ian Collins.

[Richard Heathfield]

Ian Collins said:

Richard Heathfield wrote:

>la************@ siemens.com said:

>>Bartc <[e-mail] rote:
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.
It *is* a good idea:

No, it's merely a useful consequence.

>>it forces programmers to fix their defective code.

If that were true, it would be a pity that it isn't guaranteed by the
Standard. But it isn't true, of course. Some programmers never even see
the crashes, let alone fix their causes. [example snipped] Clearly the
programmer never bothered to test this execution path, so he has /not/
been forced to fix his defective code.

But he or she would if a paying customer filed a bug report.

So what you're saying is that the crash in itself is not sufficient to
force the programmer to fix the defective code. This doesn't appear to
contradict anything I said above.

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

[Richard Heathfield]

CBFalconer said:

Ian Collins wrote:

>CBFalconer wrote:

... snip ...

>>

>>However fclose doesn't crash on receiving a NULL. It returns EOF.

Says who? The behaviour is undefined.

Says the standard.

<snip>

>
[#3] The fclose function returns zero if the stream was
successfully closed, or EOF if any errors were detected.

Note the phrase "any errors" in the line above.

Note that the implementation is not *obliged* to detect the error of
passing NULL to this function. The Standard merely documents the result if
such an error /is/ detected. The behaviour if you pass NULL to fclose
remains undefined.

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

[Richard Heathfield]

CBFalconer said:

Richard Heathfield wrote:

>>

... snip ...

>>
Undefined behaviour need not have the same effect on my system as
it does on yours. I was under the impression that you already
knew that.

See my reply to Ian.

See my reply to your reply to Ian.

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