On Sun, Jan 14, 2024 at 9:04 PM Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sunday, 14 January 2024 16:27:31 PST connor horman via Std-Proposals
> wrote:
> > Not to mention, you've got (at least) two incompatible name mangling
> ABIs,
> > and I doubt very much that either will want to break basically every one
> of
> > their users by so radically altering their definition.
>
> There's the ABI that everyone but one uses, and there's the defective
> [Microsoft] ABI.
> [Microsoft] should really make a plan to fix it, so it may
> as well figure out if there's a "flag day" when they just switch to the
> common
> ABI.
>
> [The Microsoft] ABI has several known defects, including:
> [...]
> Those aren't just quirks of the ABI. They cause failures to conform to the
> C++
> standard.


Every ABI has such failures, to some extent. (The problem is that ABIs by
definition are fixed artifacts, whereas the paper standard keeps moving
and/or fixing its own bugs.)
For example, lately I've been looking at exception handling. The Itanium
ABI miscompiles the following program:
    void f() { static int i; throw &i; }
    int main() { try { f(); } catch (void*&) {} catch (const void*&) {
puts("OK"); } }
by taking the first catch block instead of the second. That's because the
Itanium ABI simply *does not preserve enough information in RTTI* to
distinguish those two catch-blocks' types. See:
https://quuxplusone.github.io/blog/2023/11/17/reinterpret-cast-via-throw/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23257

Another perennial ABI woe (present on all platforms I'm aware of) is that
e.g. `unique_ptr` can't be passed in a register.
https://quuxplusone.github.io/blog/2018/05/02/trivial-abi-101/

If we were designing a new ABI from scratch, then naturally we'd fix all
the problems *we were aware of at the time*. But new problems would crop up
immediately, and be immediately unfixable, because *that's what ABI means*.

–Arthur