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
53  4483 
Bartc said:
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.
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.
<snip>
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.
Well, of course it could, but it isn't obliged to. One of the ways an
implementation can hand you astounding performance is to keep the
error-checking down to an absolute minimum, trusting you to do any
necessary checks yourself (because the alternative is to do the checks,
even when *you* know they're not needed).
Was I unlucky or is it normal for C library functions to be so fragile?
C trusts you. Be worthy of that trust, or use a different language.
--
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
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.
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?
According to the standard fclose must return EOF if "errors were
detected". However it says nothing about the range of possible errors.
Is it an error if the operation fails to close a file with an otherwise
perfectly valid FILE * parameter? According to the standard the answer
is a clear yes. Is it also an error if the argument to fclose is an
illegal or invalid pointer value? The standard doesn't explicitly
address this issue, but I think the intent is to treat an illegal
pointer value (basically NULL and other trap representations ) as a
failure, and hence return EOF. OTOH an invalid pointer value cannot be
detected by most implementations of fclose and I think it invokes
undefined behaviour, whose result might be anything from a crash to
returning EOF.
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. So it becomes a QoI issue and it seems that DigitalMars has
the best behaviour of your test set.
"Bartc" <bc@freeuk.comw rites:
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.)
Error. Read the manual.
>
Was I unlucky or is it normal for C library functions to be so fragile?
-- Bart
I like it when they crash. It means I dont have to check the return code
for error conditions and my debugger tells me straightaway where it
broke.
Why would I want the libraries to cover up my sloppy mistakes?
Excessive error checking to cover for lazy programmers might well add
unnecessary overheads.
"Bartc" <bc@freeuk.comw rites:
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.
Not everyone will expect the same thing!
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.
Of course it can. The behaviour is undefined so it may check (or not
check) anything it likes in this case. What has the emphasis of this
group got to do with what a standard library function does?
(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.)
Yes, I agree that it is annoying that one can't fclose the result of
fopen (like one can free the result of malloc) but such is C.
Was I unlucky or is it normal for C library functions to be so
fragile?
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.
--
Ben.
"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("fclose (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().
>One of the ways an
implementation can hand you astounding performance is to keep the
error-checking down to an absolute minimum
This is a /file/ operation. The cost of the check is negligible compared to
the file processing time.
C trusts you. Be worthy of that trust, or use a different language.
I was. But I was interpreting it using a C program. I will have to put in
extra checks for possible uses of NULL file handles that can crash C, to
keep that other language robust.
--
Bartc
"Ben Bacarisse" <be********@bsb .me.ukwrote in message
news:87******** ****@bsb.me.uk. ..
"Bartc" <bc@freeuk.comw rites:
>status=fclose( 0);
>crashes on the first two implementations I tried. Then I tried DMC and
that
gave the expected EOF status.
Not everyone will expect the same thing!
>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.
Of course it can. The behaviour is undefined so it may check (or not
check) anything it likes in this case. What has the emphasis of this
group got to do with what a standard library function does?
Something to do with setting an example?
If a writer of a library function can't check a handle (for a common error
like NULL, in a non-speed-critical function) why should anybody else?
It's normal. Have you tried strlen(0), strcpy(0, 0) or fopen(0, 0)?
I know about null string pointers. I'd prefer the library to be tolerant of
them.
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.
That's true. And if I did have a file that needed closing then fclose(0)
returning EOF wouldn't tell me there was a problem (although I would find
out in due course).
But then, it may crash quietly.
What's wrong with fclose() doing something like: "ABORTING: Invalid handle
to fclose()".
--
Bartc
"Bartc" <bc@freeuk.comw rites:
"Ben Bacarisse" <be********@bsb .me.ukwrote in message
news:87******** ****@bsb.me.uk. ..
>"Bartc" <bc@freeuk.comw rites:
>>status=fclose (0);
>>crashes on the first two implementations I tried. Then I tried DMC and
that
gave the expected EOF status.
Not everyone will expect the same thing!
>>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.
Of course it can. The behaviour is undefined so it may check (or not
check) anything it likes in this case. What has the emphasis of this
group got to do with what a standard library function does?
Something to do with setting an example?
If a writer of a library function can't check a handle (for a common error
like NULL, in a non-speed-critical function) why should anybody else?
Because it has a documented range of inputs. Why waste time? This is not
ADA. It is C.
"Bartc" <bc@freeuk.comw rites:
"Ben Bacarisse" <be********@bsb .me.ukwrote in message
news:87******** ****@bsb.me.uk. ..
>"Bartc" <bc@freeuk.comw rites:
>>status=fclose (0);
>>crashes on the first two implementations I tried. Then I tried DMC and
that
gave the expected EOF status.
Not everyone will expect the same thing!
>>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.
Of course it can. The behaviour is undefined so it may check (or not
check) anything it likes in this case. What has the emphasis of this
group got to do with what a standard library function does?
Something to do with setting an example?
I am confused as to which way round the example should be set. Maybe
you are surprised by how keen we are on error checking, given how lax
the library is? I don't know, but I don't think that is your main
point.
Anyway, I don't think there *is* an emphasis on functions checking their
input. There certainly is on checking the results, but that is not
the same. I think most regulars here will have caught the C bug of
doing rather minimal checking *in* a function. See, for example, the
recent posts about K&R solutions -- most of the examples posted ensure
that a function is called correctly and don't re-check inside.
If a writer of a library function can't check a handle (for a common error
like NULL, in a non-speed-critical function) why should anybody else?
>It's normal. Have you tried strlen(0), strcpy(0, 0) or fopen(0, 0)?
I know about null string pointers. I'd prefer the library to be tolerant of
them.
Then you'll have to write a set of wrappers.
>Luck is another matter. In a way you were lucky that at least one
implementati on 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.
That's true. And if I did have a file that needed closing then fclose(0)
returning EOF wouldn't tell me there was a problem (although I would find
out in due course).
But then, it may crash quietly.
What's wrong with fclose() doing something like: "ABORTING: Invalid handle
to fclose()".
Nothing, except that there is an assumption that the library does not
write error messages. I don't think it is forbidden, it is just not
expected (at least on the systems I am used to).
--
Ben.
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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: VB |
last post by:
Hi,
here File.cpp and File.h:
File.cpp:
----------------------
#pragma warning (disable: 4786)
|
by: Jeff |
last post by:
If this in not an ANSI-C question, then just flame me and I'll be on my
way....
I am using fdopen to associate a FILE with a socket descriptor. (Because
I've mentioned a socket descriptor I anticipate the flame. But I believe
this is a C question.) My problem is this: if the socket is closed and I
pass the FILE returned from fdopen to fclose, my program dies with a
memory fault. My question: why do I get a memory fault with fclose when...
|
by: collinm |
last post by:
hi
is it better to do:
FILE *fp;
if((fp = fopen(local_led, "r"))!=NULL)
{
fclose(fp);
}
else
|
by: lihua |
last post by:
Hi, Group!
I got one question here:
We all know that fclose() must be called after file operations to
avoid unexpected errors.But there are really cases when you forget to
do that!Just
like what happens in memory operations, everyone knows the importance
of
freeing the allocated memory, but there do have memory leaks from time
to
|
by: kathy |
last post by:
if fopen failed, does it necessary to call fclose?
I see an example like this:
....
stream = fopen(...);
if(stream == NULL)
{
....
}
else
| | |
by: David Mathog |
last post by:
A program of mine writes to a tape unit. Output can be either through
stdout or through a file opened with fopen(). When all the data is
transferred to tape the program needs to close the output stream so that
the tape driver will write a filemark on the tape. Otherwise multiple
clumps of data saved to tape would all appear to be one big file on the
tape.
When the tape unit device was explicitly opened with fopen()
that's possible:...
|
by: Bill Cunningham |
last post by:
Is it really necessary to check the return type (int) or fclose ? fopen
I can understand but what about using
fflsuh(fp); /* fopen's pointer */
fclose(fp);
Would that take care of any unforseen truncation ?
Bill
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth.
The Art of Business Website Design
Your website is...
| | |
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
| |
