On Sun, 12 Apr 1998, Hamish Moffatt wrote: > > The point here is that it's _documented_ to return EBADF if the stream > > pointer is not an open stream, and that's not what happens. This is > > difficult to enforce in practice, and is not necessary for ISO compliance -- > > so let's fix the man page. > > Is it really so difficult to handle this situation though? Using > Steve's test program on Solaris does as expected:
Yes, it would be quite difficult to do efficently. There's no good way to tell that the pointer you're passing is _really_ a FILE* pointer. Once it's closed, the pointer's value is meaningless. There are various ways you could keep fclose() from crashing if you give it an invalid pointer (eg. keep a linked list of all open files, and only close the file if you find it in the list) but that wastes memory and is slow. If you try to fclose(NULL) (like when the file can't open and you close it anyway) it's easy to ignore -- just return immediately if the file pointer is NULL. But should we do that? Personally, as a programmer myself, I much prefer to work on a system that gives up consistently when I do something wrong. That's what segmentation faults are all about. It would be _easy_ to tell the kernel "don't kill tasks if they write to random memory locations." That's what DOS and Win16 did -- and you end up with random memory corruption that's virtually impossible to debug. Note that libc5 apparently didn't crash (at least, hylafax worked) when you double-fclosed a file, but that wasn't because of any feature of libc5. It was just lucky enough to avoid hitting any memory areas the wrong way. Anyone who can operate GDB should be able to track down a crash in fclose() as long as it segfaults properly. But the fclose() behaviour should be documented... the way I usually phrase it in my own API documentation is something like "a call to this function causes the pointer to become invalid, and it should not be used in subsequent function calls." Have fun, Avery P.S. I'll try Solaris at work on Tuesday. I suspect its non-crashing behaviour is just good luck on their part. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
