[Bug libstdc++/71950] std::ios_base::failure.what() returns irrelevant error message

["redi at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71950

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Austin Kramer from comment #2)
> Well, if the actual throw happens obliviously in basic_ios::clear after
> fstream::open detects the error, it wouldn't be hard to have fstream::open
> catch the exception and re-throw a more helpful one.

That would add overhead for exception handling and the vast majority of users
do not use exceptions with fstream.

 The real hard part
> though is propagating the error details up to fstream::open in the first
> place. The call stack goes through several basic succeed/fail returns, some
> of which are public-facing functions.
> 
> There are 2 reasonable solutions I can think of that don't break the API,
> but neither are particularly clean.
> 
>  - Gratuitous overloading: Replace some intermediate basic_filebuf and
> __basic_file calls with ones that propagate an error code, and have their
> public-facing variants wrap the new versions and reduce the return value to
> the compliant types.

Users can specialize basic_filebuf so we can't rely on non-standard functions.

I don't think it's worth changing anything here.