I have a simple program that should show the problem. - with libc++ the stream is still good after closing and further operation. Since also the file content was not updated - at least the stream operation fails on the closed stream and should set either failbit or badbit to reflect the situation. #include <iostream> #include <fstream> int main(int argc, const char * argv[]) { std::fstream ofs("test.txt", std::ios::out | std::ios::trunc); ofs << "Hello, World!\n"; ofs.close(); ofs << "Hello, World!\n"; std::cout << "good(): " << ofs.good() << " fail(): " << ofs.fail() << " bad(): " << ofs.bad() << " eof(): " << ofs.eof() << std::endl; return 0; } // http://coliru.stacked-crooked.com/a/cfaeb32849c9cfad With libc++ I get good(): 1 fail(): 0 bad(): 0 eof(): 0 Expected (or with libstdc++): good(): 0 fail(): 1 bad(): 1 eof(): 0 I have tested on OSX with Xcode 9.4.1 Apple LLVM version 9.1.0 (clang-902.0.39.2) or on Linux: clang version 3.8.0
This is https://stackoverflow.com/questions/51137052/libc-why-is-the-stream-still-good-after-closing (which I think you wrote, too) The answer I gave there is still correct. The standard says nothing about doing things to an fstream after calling close - so libc++'s behavior here is not "non-standard". However, it is definitely surprising. I have a patch that makes libc++ act like libstdc++, but I'm still looking into this. Index: include/fstream =================================================================== --- include/fstream (revision 338379) +++ include/fstream (working copy) @@ -702,6 +702,7 @@ __file_ = 0; else __rt = 0; + setbuf(0, 0); } return __rt; }
Committed r350603 to resolve this.