Date: Sun, 07 Aug 2022 15:51:17 -0700
On Sunday, 7 August 2022 14:31:23 PDT Jonathan Tanner wrote:
> > Another issue is that a change in ABI of trivial types affect the C
> > language too.
>
> I don’t think it will, all C types are trivially destructible in C++ and for
> trivially destructible types neither the caller nor the callee need destroy
> them.
They still have storage space in the stack. The proposal affects how functions
may reuse that storage, which can change any number of behaviours. C++
compilers don't exist in isolation -- all of the extant ones are just a
slightly different front-end to the same C compiler. The whole reason why the
C++ ABI was designed with caller-destroys is because in the C psABI, the
caller reclaims the stack space on Unix systems, but the callee does on
Windows. Changing the stack reclamation would indeed affect C; changing just
one aspect of this and not the other is bound to run into any number of 25-
year-old entanglements no one remembers they existed.
You're right that standards-compliant code should not be affected. But remember
the truism that "in theory, theory in practice are the same, in practice
they're not". We have to deal with any number of illegal but previously
working code (for some definition of "working") too.
Let me give you an example: the vectorised implementations of memcmp() must,
after finding a difference in the vectors, compute which byte had the difference
and return a result. But bcmp() doesn't have to do that: it just says 0 for
equal, non-zero for non-equal. However, bcmp() has been implemented as an
alias to memcmp() for so long that any number of software may be relying on
the previous implementation behaviour that wasn't dictated by the standard. So
glibc rejected changing bcmp() even if it makes valid code faster, because
it's too risky.
Which is why I said distributions won't do it. And there are more reasons not
to do an ABI break. It would be easier to convince people to switch to
FreeBSD.
> > Another issue is that a change in ABI of trivial types affect the C
> > language too.
>
> I don’t think it will, all C types are trivially destructible in C++ and for
> trivially destructible types neither the caller nor the callee need destroy
> them.
They still have storage space in the stack. The proposal affects how functions
may reuse that storage, which can change any number of behaviours. C++
compilers don't exist in isolation -- all of the extant ones are just a
slightly different front-end to the same C compiler. The whole reason why the
C++ ABI was designed with caller-destroys is because in the C psABI, the
caller reclaims the stack space on Unix systems, but the callee does on
Windows. Changing the stack reclamation would indeed affect C; changing just
one aspect of this and not the other is bound to run into any number of 25-
year-old entanglements no one remembers they existed.
You're right that standards-compliant code should not be affected. But remember
the truism that "in theory, theory in practice are the same, in practice
they're not". We have to deal with any number of illegal but previously
working code (for some definition of "working") too.
Let me give you an example: the vectorised implementations of memcmp() must,
after finding a difference in the vectors, compute which byte had the difference
and return a result. But bcmp() doesn't have to do that: it just says 0 for
equal, non-zero for non-equal. However, bcmp() has been implemented as an
alias to memcmp() for so long that any number of software may be relying on
the previous implementation behaviour that wasn't dictated by the standard. So
glibc rejected changing bcmp() even if it makes valid code faster, because
it's too risky.
Which is why I said distributions won't do it. And there are more reasons not
to do an ABI break. It would be easier to convince people to switch to
FreeBSD.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2022-08-07 22:51:19