Date: Sun, 31 May 2026 17:02:17 -0700
*>> 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 <cxx_at_[hidden]>: *compile_assert() *looks like a good
idea to me.
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.
Too bad it takes so long for new C++ features to reach stable Linux
distributions.
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 <cxx_at_[hidden]>: *compile_assert() *looks like a good
idea to me.
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.
Too bad it takes so long for new C++ features to reach stable Linux
distributions.
Received on 2026-06-01 00:02:31
