This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

Austin Kramer <skaianhero at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |skaianhero at gmail dot com

--- Comment #2 from Austin Kramer <skaianhero at gmail dot com> ---
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. 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.

 - Just use errno: AFAIK there's no spec saying that errno should be set in a
fstream::open call (from the perspective of the caller), but in practice it
seems to be set to the correct value for the underlying I/O error (though this
may be platform-dependent). If g++ could internally require errno to be set
deeper within the file operations and remain set until control returns to
fstream's functions, then those functions could re-throw a fresh exception
after basic_ios::clear with a more helpful message. But like you said, it's
hard (and perhaps wrong) to fully ensure that all sources of errors set errno
appropriately.

That said, I'm not sure how, in a world without PR 66145 causing issues, the
C++11 version would cleanly propagate the system_error details. Maybe it just
doesn't, and this fix would be used to address that as well.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]