On Mon, 22 Jan 2024 at 13:16, Jonathan Wakely <cxx_at_[hidden]> wrote:

>
>
> On Mon, 22 Jan 2024 at 11:52, Jan Schultke <janschultke_at_[hidden]>
> wrote:
>
>> That is a very good point.
>>
>> I have added a section which discusses the ABI implications of this
>> proposal, based on my limited knowledge. You know tremendously more
>> about libstdc++ than I do. Is my understanding that libstdc++ doesn't
>> have to take additional compatibility measures correct?
>>
>
> We would have to keep exporting the original non-inline definition for
> code already linked to an older version and expecting an extern symbol in
> the library. The new headers would define the function inline, calling
> something like your __uncaught_exceptions_impl example. That's technically
> an ODR violation, because there's an inline definition in the header and
> another non-inline definition in the library. It works though, because of
> reasons. The implementation can just declare "this doesn't violate the ODR"
> :-P
>
> The __uncaught_exceptions_impl could even be an alias for the non-inline
> uncaught_exceptions definition (or vice versa) to avoid code bloat.
>
> So I'm not concerned about the difficulty of implementing the proposal,
> but it's definitely worth mentioning.
>

I should have read your updated proposal before replying :-) The new
section looks fine, thanks.