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]

pete wrote:

Bartc wrote:

>Pointer values can be roughly grouped into these kinds:

(1) Pointing at the right thing
(2) Pointing at the wrong thing
(3) Containing an illegal address other than NULL
(4) Containing NULL

I consider object pointer values into a different four groups:
1a address of an object if provided by malloc

1b " " " " not provided by malloc

2 one past the address of an object
3 null pointer
4 indeterminate

Note my modification to 1a and 1b above. This is the cause of most
of the address checking impossibilities in C, and at the same time
much of the addressing flexibility in C.

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

>
So, the poor user writes (and I *know* this is a fragment):

FILE *fp = fopen(argv[1], "r");
if (fp) {
/* ...processing.. . */
}
else fprintf(stderr, "Failed to open %s\n", argv[1]);
if (flose(fp) == EOF)
fprintf(stderr, "Error closing %s\n", argv[1]);

How can they tell, from the EOF return, that their code is not
portable? Note that that is what I claimed. Sure, they get the two
error messages, but they expect that, surely? How does the expected
error return help then to see the non-portability of the construct?

They write:

FILE *fp = fopen(argv[1], "r");

if (!fp) fprintf(stderr, "Failed to open %s\n", argv[1]);
else {
/* ...processing.. . */
if (flose(fp) == EOF)
fprintf(stderr, "Error closing %s\n", argv[1]);
}

Notice the inversion of if and else clauses. I think it is
clearer.

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

[Ben Bacarisse]

CBFalconer <cb********@yah oo.comwrites:

Ben Bacarisse wrote:

>>

... snip ...

>>
So, the poor user writes (and I *know* this is a fragment):

FILE *fp = fopen(argv[1], "r");
if (fp) {
/* ...processing.. . */
}
else fprintf(stderr, "Failed to open %s\n", argv[1]);
if (flose(fp) == EOF)
fprintf(stderr, "Error closing %s\n", argv[1]);

How can they tell, from the EOF return, that their code is not
portable? Note that that is what I claimed. Sure, they get the two
error messages, but they expect that, surely? How does the expected
error return help then to see the non-portability of the construct?

They write:

FILE *fp = fopen(argv[1], "r");

if (!fp) fprintf(stderr, "Failed to open %s\n", argv[1]);
else {
/* ...processing.. . */
if (flose(fp) == EOF)
fprintf(stderr, "Error closing %s\n", argv[1]);
}

Notice the inversion of if and else clauses. I think it is
clearer.

<sigh Forget it.

--
Ben.

[pete]

Bartc wrote:

"pete" <pf*****@mindsp ring.comwrote in message
news:Rp******** *************** *******@earthli nk.com...

>Bartc wrote:

>>Pointer values can be roughly grouped into these kinds:

(1) Pointing at the right thing
(2) Pointing at the wrong thing
(3) Containing an illegal address other than NULL
(4) Containing NULL

I consider object pointer values into a different four groups:
1 address of an object
2 one past the address of an object
3 null pointer
4 indeterminate

I was thinking in terms of verifying pointer values passed to functions.

(4) of my list is easy. (3) and (2) are progressively more difficult. (1)
might be impossible (for the function to determine anyway).

3 on your list is again easy. But I wouldn't know how to test the others,
and if I did, the object in question might be the wrong one.

There is no portable C code way
to examine an indeterminate pointer value.

If an indeterminate pointer value is an argument to a function call,
then you're on your own.
The rules of C no longer apply to what your program will do.

--
pete