Bug 237 – std.stream.File.close() doesn't reset isopen flag

I had a code segment like this: File f = new File(filename); scope (exit) { f.close(); delete f; } However, this hang on Linux. I discovered that the deconstructor for File calls close() - which I was already calling. If I only close, or I only delete... it works. But, if I close... and later the garbage collector picks it up, I could theoretically get a hang anywhere... one I couldn't reproduce. That would be bad. AFAICT, this is simply because close() is always trying to close the open handle every time it's called. Meaning, calling close() twice in a row is not allowed. The fix is simple. Will attach. -[Unknown]

Created attachment 12 Reset isopen flag on streams. This simply flips the isopen flag on a call to close(), thus ignoring repeated calls. -[Unknown]

I've determined that this only segfaults some of the time, so this may not indeed be the problem I'm seeing. Sorry about that. I still think, regardless, that clearing the isopen flag makes sense. I'll have to do more checking to see if there's another deeper cause for the segfaulting I was seeing. -[Unknown]

The isopen flag is cleared in Socket.close which is called from File.close.