This program completes successfully despite the fact that it failed to write any data:
#include <boost/iostreams/filtering_stream.hpp>
#include <boost/iostreams/filter/gzip.hpp>
#include <fstream>
int main() {
std::ofstream s{"/dev/full"};
boost::iostreams::filtering_ostream filtering{};
filtering.push(boost::iostreams::gzip_compressor{});
filtering.push(s);
filtering << "Hello, world!";
boost::iostreams::close(filtering);
// at this point, s.good() is true
}
Debugging reveals that inside of close(), a call to pubsync() has indicated an error flushing out the data. This error is noticed by boost::iostreams's flush implementation (flush.hpp:65):
Since the compressing filters are not flushable, the only way to flush them is to close them; since this error is ignored on close, there appears to be no way in the API to discover this form of write failure when a compressing filter is in the chain.
There should be a way to avoid ignoring this error. Maybe close should throw if the call to iostreams::flush fails.
This program completes successfully despite the fact that it failed to write any data:
Debugging reveals that inside of
close()
, a call topubsync()
has indicated an error flushing out the data. This error is noticed byboost::iostreams
'sflush
implementation (flush.hpp:65
):But
flush
's result is ignored inside of theclose()
implementation (close.hpp:170
):Since the compressing filters are not flushable, the only way to flush them is to close them; since this error is ignored on close, there appears to be no way in the API to discover this form of write failure when a compressing filter is in the chain.
There should be a way to avoid ignoring this error. Maybe
close
should throw if the call toiostreams::flush
fails.