Re: Memory protection between compilation units?

On 13.06.2025 15:56, Michael S wrote:

A significant part of x86 installed base (all Intel Core CPUs starting
from gen 6 up to gen 9 and their Xeon contemporaries) has extension
named Itel MPX that was invented exactly for that purpose. But it didn't
work particularly well. Compiler people never liked it, but despite
that it was supported by several generations of gcc and probably by
clang as well.

This does not really sound like something "readily available", unless you
 are suggesting that I migrate to a Linux kernel from 10 years ago, switch
 to gcc 5.0 and use outdated hardware.

The proper solution to your problem is to stop using memory-unsafe
language for complex application programming. It's not that successful
use of unsafe languages is for complex application programming is
impossible. The practice proved many times that it can be done. But
only by very good team. You team is not good enough.

Just to clarify: I didn’t post here seeking help with a simple out-of-bounds
 issue, nor was I here to vent. I’ve been wrangling C code in complex,
 high-performance systems for over a decade - I’m managing just fine. Code
 improvement is a continual, non-negotiable process in our line of work, but
 fires happen occasionally nonetheless. While fixing the issue, I started
 wondering about how faults like this could be located faster, that is
 assuming they do slip into production - because in spite of the testing
 process, some faults will inevitably get to customers.
A crash that happens closer to the source of the problem (same compilation
 unit) would significantly ease the debugging effort. I figured it was a
 topic worth sharing, in the spirit of sparking some constructive
 discussions.
Mateusz