--- Comment #6 from Jonathan Wakely <redi at gcc dot> ---
(In reply to from comment #5)
> On Thu, 5 Apr 2018, redi at gcc dot wrote:
> >
> > 
> > --- Comment #4 from Jonathan Wakely <redi at gcc dot> ---
> > (In reply to Richard Biener from comment #3)
> > > Do you know of any other exception type affected by the c++11 vs. old ABI
> > > issue or does the entire I/O hierarchy only ever throw exactly
> > > ios_base::failure?
> > 
> > That's the only one.
> > 
> > > So a workaround would be to marshal these somehow in the C++ EH 
> > > personality
> > > routine?  The c++11 variant seems to be a superset feature-wise (apart 
> > > from
> > > the changed inheritance), so constructing (in-place?!) the c++98 variant
> > > once we hit a filter for c++98 ios_base::failure with an EH object of
> > > type ios_base::failure[c++11] would "work"?
> > 
> > Until you try to rethrow it and catch it as the new type again.
> Ok, but that would be an even more weird case of an intermediate
> old-ABI object sitting inbetween the c++11 throwing libstdc++ and
> a c++11 object.

Which can happen with a legacy shared library trying to catch the old
ios::failure, log something, and then re-throw it. If that shared library is
used by a program where the main() function is using the new ABI and main()
tries to catch ios::failure at the top-level, it won't be able to if the
exception was replaced by another type.

> So the old std::ios::failure doesn't fit in the new one?

It fits, but overwriting it in place can create data races and invalidate
existing references to the original object that was overwritten.

>  As said
> above I consider the re-throwing and catching as c++11 a situation
> that shouldn't be required for fixing the "legacy" binary case.

It's not required to fix the simple case of a legacy binary using a new but it breaks other cases.

Reply via email to