On 01/06/2026 07:59, Jonathan Wakely via Std-Proposals wrote:
>
>
> On Mon, 1 Jun 2026, 01:02 Adrian Johnston, <ajohnston4536_at_[hidden] <mailto:ajohnston4536_at_[hidden]>> wrote:
>
>
> />> But then how do you prove that you can't blow up the stack?/
>
> It depends on the standards you set for proof. If, as in your case, hundreds of lives are at stake then I can understand saying the "linker is responsible" because it is easier to provide formal verification.
>
> Otherwise, you can write tests that trap allocations at the wrong time.
>
> @Jonathan Wakely <mailto:cxx_at_[hidden]>: *compile_assert() *looks like a good idea to me.
>
>
>
> I think you mean Jonathan Grant?

Yes that's me, compile_assert I described here:

compile_assert() – control-flow enforced conditions at compile-time
https://isocpp.org/files/papers/P4021R2.pdf

>
>
> It would make for a great variant of *std::inplace_vector::unchecked_push_back*. E.g. *std::inplace_vector::assert_push_back*.
>
> I just realized how quickly you can end up reinventing Rust by going down that road. Anyway, I would prefer enforcement at runtime as a library hardening feature. If RAM errors and unreachable code getting executed are important to you than you would want hardening anyway.
>

It's good to check things at runtime that can't be checked at compile time on a safety critical system, however the question then is what to do when EB Erroneous Behaviour is determined at runtime on a safety critical system? What way would you handle an issue identified by library hardening?

It's still a pain even for desktop users if an application closes.

Kind regards, Jonathan Grant

> Too bad it takes so long for new C++ features to reach stable Linux distributions.
>
>