Re: Is this a bug in libc6?
Avery Pennarun <apenwarr@worldvisions.ca> writes:
> On Sun, 12 Apr 1998, Hamish Moffatt wrote:
> > 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.
One cheap solution which will usually work is to put a magic number at the
head of the FILE* structure and clear it when the close is done (before the
free). This doesn't work 100% of the time but in practice would it would work.
> 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.
Well, the problem with the current setup is really that it may or may not
crash depending on what data is in the previously allocated structure. It's a
source of randomness which is always bad for debugging.
And not all programs running with this library were developped with this
library. For people compiling software that was developped under solaris
or libc5, this will be a real pain.
I don't know if there are any run-time debugging flags for glibc, if there are
making this print a warning if they're set and always return EBADF would be
ideal, imho.
greg
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: