fclose(0)

[CBFalconer]

Re: fclose(0)

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]

Re: fclose(0)

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@siemens.com]

Re: fclose(0)

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

Re: fclose(0)

CBFalconer wrote:

Chris Torek wrote:

>Eric Sosman <esosman@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]

Re: fclose(0)

lawrence.jones@ siemens.com said:

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

Re: fclose(0)

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]

Re: fclose(0)

Richard Heathfield wrote:

lawrence.jones@ siemens.com said:
>

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

Re: fclose(0)

Ian Collins said:

Richard Heathfield wrote:

>lawrence.jones@ siemens.com said:
>>

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

[CBFalconer]

Re: fclose(0)

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.

7.19.5.1 The fclose function

Synopsis
[#1]
#include <stdio.h>
int fclose(FILE *stream);

Description

[#2] The fclose function causes the stream pointed to by
stream to be flushed and the associated file to be closed.
Any unwritten buffered data for the stream are delivered to
the host environment to be written to the file; any unread
buffered data are discarded. The stream is disassociated
from the file. If the associated buffer was automatically
allocated, it is deallocated.

Returns

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

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

Re: fclose(0)

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.

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


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

[Richard Heathfield]

Re: fclose(0)

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]

Re: fclose(0)

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

[Ian Collins]

Re: fclose(0)

CBFalconer wrote:

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.
>
Returns
>
[#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.
>

See Richard's reply to your reply to my reply.

--
Ian Collins.

[santosh]

Re: fclose(0)

Richard Tobin wrote:

In article <fuvh9u$mlt$1@r egistered.motza rella.org>,
santosh <santosh.k83@gm ail.comwrote:

>>So for the code in question I'd say that conforming compilers are
>>allowed to do anything since the behaviour is undefined (not
>>explicitly stated in the standard, but inferred) upon giving fclose an
>>illegal argument.

>
The standard *does* say that you get undefined behaviour if you pass
null to a library function expecting a pointer unless it explicitly
says you can. So the behaviour is certainly undefined.

Okay. I guess it says this somewhere else. IMHO, it should also have
been added to the description of fclose and other functions that are
not defined for a null pointer parameter.

[santosh]

Re: fclose(0)

Richard Heathfield wrote:

Ian Collins said:
>

>Richard Heathfield wrote:

>>lawrence.jones@ siemens.com said:
>>>
>>>Bartc <bc@freeuk.comw 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.

I suppose Larry implied crashes during development and in-house testing.
But a crash isn't guaranteed even in this case. It's merely an outcome
on several common platforms.