Re: Memory protection between compilation units?

Am 11.06.2025 um 15:32 schrieb Mateusz Viste:

While the presented issue is common knowledge for anyone familiar with
C, *locating* the bug was challenging. The program did not crash at the
moment of the out-of-bounds write but much later - somewhere entirely
different, in a different object file that maintained a static pointer
for tracking a position in a linked list. To my surprise, the pointer
was randomly reset to NULL about once a week, causing a segfault.
Tracing this back to an unrelated out-of-bounds write elsewhere in the
code was tedious, to say the least.

Therefore I love bounds-checking C++ containers with MSVC (debug builds)
and with the libstdc++ runtime (enabled via macro). With that the bug
still remains in release-builds, but anyone who has access to the source
can run the code and apply suspicious input and can determine if there's
a bounds violation without knowing how the code works.
But sometimes you've got a simple memory range, usually from a C-API.
With that I use a C++20 span, that internally is usually a pointer and
a size_t. If you apply f.e. an indexed access on it the []-operator
checks the bounds with that.
Debug builds are usually much slower, but if you use C++ that's even
more slower since simple things like a container acces via []-operator
occur with a separate function call while debugging. With iterator
-debugging that's even slower. But this price is worth the advantage
that you can easily find bounds-problems with C++.

This raises a question: how can such corruptions be detected sooner?

Use C++.