Date: Mon, 22 Jan 2024 13:16:17 +0000
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.
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.
Received on 2024-01-22 13:17:33