Date: Sun, 08 Jun 2025 14:48:27 -0700
> On Jun 8, 2025, at 1:45 AM, Avi Kivity via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Sun, 2025-06-08 at 00:24 +0300, Ville Voutilainen wrote:
>> On Sun, 8 Jun 2025 at 00:20, Avi Kivity <avi_at_[hidden] <mailto:avi_at_[hidden]>> wrote:
>>
>>> That's easy. The hard part is figuring out how to deploy such a type
>>> with the same name as its previous version that didn't use
>>> the dummy value protocol. It's a behavioral ABI break without any
>>> layout ABI break.
>>>
>>>
>>>
>>> This was solved already when std::string changed its ABI. The compilers shipped the standard library compiled in both modes for a while, then dropped the old mode.
>>
>> Sure, but it was painful. Very painful. It's not quite that painful
>> for std::optional, because it's not used elsewhere in the library
>> internals.
>> But still, it's painful.
>
>
> It wasn't painful for me - I barely noticed it. Of course, everyone's mileage varies.
>
> In my opinion, in these days of containers, it's much easier to support multiple ABIs.
That’s simply not true.
Most applications do not ship with what is essentially a clone of userspace - which is all that containers really are.
What you’re suggesting actually makes it worse: now every application would be *required* to be a container because they lose access to the platform userspace.
That means larger applications, more physical memory use per application, slower application launch times, larger attack vectors as applications do not automatically get security updates from the OS (because they no longer use the OS libraries).
The security problem is not hypothetical: attacks on containers running with out of date software, even when the host is running up to date versions of the relevant libraries and applications, is a well documented and persistent problem.
>>> Of course this little thing isn't worth the trouble, but libraries could use a spring cleaning anyway (like make std::deque's default constructor not allocate) and this could be added on top. Library vendors that choose not to improve, would simply not implement the feature.
>>
>> I don't think the cost of the next ABI break goes to zero after the
>> first one, so it isn't immediately obvious to me that such a change
>> would necessarily open
>> a practical door to making more breaks. It probably would, but that
>> does depend on how much a nuisance the first one is and how much time
>> is left for the following
>> ones. :)
>
>
> I don't think the Standard should concern itself with ABIs. It should promote source compatibility. It should be up to the vendors to decide whether to race ahead or be conservative.
The moment you say “the ABI does not matter” you essentially say C++ is no longer fit for use as a platform/OS API, it is no longer fit as the interface to libraries, and it is not longer fit for use in any application or environment where objects are being shared across library boundaries.
It’s important that you recognize that while you do not care about other people’s use cases, not everyone agrees with your assertions that every application should just ship with its own user space, and drop down to C interfaces whenever they want to use OS services (syscalls, user interface libraries, audio, etc).
I do understand that there are platforms where containers are seemingly the only (or at least the easiest) mechanism for shipping applications such that they work reliably, but that is not a universal property of all platforms. Many platforms permit a single build of the application that runs consistently across many major releases - generally only failing after features are deprecated and eventually removed. Even then some platforms do not remove such features, just making it inaccessible to new software so that application updates need to migrate to newer APIs as the update their release targets.
> Distribution vendors already rebuild all their packages for each major release, and third-party vendors already build for multiple architectures. Having them build for the most recent and next-recent ABI is annoying, but not more than that.
No, having them *rebuild* their software for every release is annoying, and is not required on every platform. You’re trying to make claims that ABI stability does not matter simply because your primary (only?) target has not managed to provide the bare minimum abi stability guarantees other platforms seem perfectly capable of.
You’re saying “my platform does not provide a stable C++ ABI so the standard should not concern itself with ABI stability”. I can make the inverse proposal, that is actually much stronger, and actually useful: The C++ standard should pay attention to the ABI, specifically it should specify the exact ABI of all interfaces. That would be a huge win because it would mean on your target platform third parties would stop needing to rebuild their products for ever release even though there have not been any changes that matter to them, it would mean an application compiled against one implementation or version of the standard library could operate on a system with not just a different version of the standard library (something that multiple platforms already support), but also completely different implementations of the standard library. e.g. It would allow third parties to ship software without caring about whether the client’s system is set up to use stdlibc++ or libc++, etc.
A final note: building and shipping multiple architectures is a significant resource sink. It makes updates much larger, it makes the install OS larger, it increases the in memory footprint if applications targeting different architectures are loaded, etc. It’s not free to the developer or the end user. Again this seems to be you saying “these costs don’t matter to me, so it’s reasonable to force everyone else to take on those same costs”.
—Oliver
>
> On Sun, 2025-06-08 at 00:24 +0300, Ville Voutilainen wrote:
>> On Sun, 8 Jun 2025 at 00:20, Avi Kivity <avi_at_[hidden] <mailto:avi_at_[hidden]>> wrote:
>>
>>> That's easy. The hard part is figuring out how to deploy such a type
>>> with the same name as its previous version that didn't use
>>> the dummy value protocol. It's a behavioral ABI break without any
>>> layout ABI break.
>>>
>>>
>>>
>>> This was solved already when std::string changed its ABI. The compilers shipped the standard library compiled in both modes for a while, then dropped the old mode.
>>
>> Sure, but it was painful. Very painful. It's not quite that painful
>> for std::optional, because it's not used elsewhere in the library
>> internals.
>> But still, it's painful.
>
>
> It wasn't painful for me - I barely noticed it. Of course, everyone's mileage varies.
>
> In my opinion, in these days of containers, it's much easier to support multiple ABIs.
That’s simply not true.
Most applications do not ship with what is essentially a clone of userspace - which is all that containers really are.
What you’re suggesting actually makes it worse: now every application would be *required* to be a container because they lose access to the platform userspace.
That means larger applications, more physical memory use per application, slower application launch times, larger attack vectors as applications do not automatically get security updates from the OS (because they no longer use the OS libraries).
The security problem is not hypothetical: attacks on containers running with out of date software, even when the host is running up to date versions of the relevant libraries and applications, is a well documented and persistent problem.
>>> Of course this little thing isn't worth the trouble, but libraries could use a spring cleaning anyway (like make std::deque's default constructor not allocate) and this could be added on top. Library vendors that choose not to improve, would simply not implement the feature.
>>
>> I don't think the cost of the next ABI break goes to zero after the
>> first one, so it isn't immediately obvious to me that such a change
>> would necessarily open
>> a practical door to making more breaks. It probably would, but that
>> does depend on how much a nuisance the first one is and how much time
>> is left for the following
>> ones. :)
>
>
> I don't think the Standard should concern itself with ABIs. It should promote source compatibility. It should be up to the vendors to decide whether to race ahead or be conservative.
The moment you say “the ABI does not matter” you essentially say C++ is no longer fit for use as a platform/OS API, it is no longer fit as the interface to libraries, and it is not longer fit for use in any application or environment where objects are being shared across library boundaries.
It’s important that you recognize that while you do not care about other people’s use cases, not everyone agrees with your assertions that every application should just ship with its own user space, and drop down to C interfaces whenever they want to use OS services (syscalls, user interface libraries, audio, etc).
I do understand that there are platforms where containers are seemingly the only (or at least the easiest) mechanism for shipping applications such that they work reliably, but that is not a universal property of all platforms. Many platforms permit a single build of the application that runs consistently across many major releases - generally only failing after features are deprecated and eventually removed. Even then some platforms do not remove such features, just making it inaccessible to new software so that application updates need to migrate to newer APIs as the update their release targets.
> Distribution vendors already rebuild all their packages for each major release, and third-party vendors already build for multiple architectures. Having them build for the most recent and next-recent ABI is annoying, but not more than that.
No, having them *rebuild* their software for every release is annoying, and is not required on every platform. You’re trying to make claims that ABI stability does not matter simply because your primary (only?) target has not managed to provide the bare minimum abi stability guarantees other platforms seem perfectly capable of.
You’re saying “my platform does not provide a stable C++ ABI so the standard should not concern itself with ABI stability”. I can make the inverse proposal, that is actually much stronger, and actually useful: The C++ standard should pay attention to the ABI, specifically it should specify the exact ABI of all interfaces. That would be a huge win because it would mean on your target platform third parties would stop needing to rebuild their products for ever release even though there have not been any changes that matter to them, it would mean an application compiled against one implementation or version of the standard library could operate on a system with not just a different version of the standard library (something that multiple platforms already support), but also completely different implementations of the standard library. e.g. It would allow third parties to ship software without caring about whether the client’s system is set up to use stdlibc++ or libc++, etc.
A final note: building and shipping multiple architectures is a significant resource sink. It makes updates much larger, it makes the install OS larger, it increases the in memory footprint if applications targeting different architectures are loaded, etc. It’s not free to the developer or the end user. Again this seems to be you saying “these costs don’t matter to me, so it’s reasonable to force everyone else to take on those same costs”.
—Oliver
Received on 2025-06-08 21:48:45