Subject: Re: [boost] [iostreams] libstdc++ vs MSVC exception handling behavior in seekg, seekp
From: Bo Persson (bop_at_[hidden])
Date: 2018-07-17 20:17:14
On 2018-07-17 18:17, James E. King III via Boost wrote:
> I found a disabled test in Boost.Iostreams called stream_state_test. It
> was disabled because it was thought it only tests the standard library
> implementation. Partially true, but it also tests some parts of iostreams
> so I have been working to re-enable it along with the generic CI upgrades.
> It looks like libstdc++ and the standard library that comes with MSVC (is
> it still Dinkumware? It used to be...) handle exceptions on stream seekg
> and seekp differently. I haven't consulted the standards documents yet,
> but I found this reference for exception handling:
> http://www.cplusplus.com/reference/istream/istream/seekg/ which states, " Any
> exception thrown by an internal operation is caught and handled by the
> function, setting badbit <http://www.cplusplus.com/ios_base::badbit>. "
> Sitting in the debugger where the test throws an exception in
> error_device::seek, there is no exception handling within iostreams or in
> msvcp140d code paths for a call to seekg, while the libstdc++
> implementation is able to pass all of the tests. This leads to a couple
> 1. Are the standards clear in this area?
> 2. Is someone violating them?
> A cursory review (such as this) leads me to believe that the MSVC C++
> runtime implementation is not properly handling exceptions here. The
> sources for seekg in libstdc++ wrap the internals in a try catch in order
> to restore state. The sources for seekg in the MSVCPRT do not.
seekg is defined as calling pubseekoff which is calling seekoff that is
defined to return an error code on failure.
So who is going to throw an exception (aside from a mocking test case)?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk