Sujet : Re: Memory protection between compilation units?
De : mateusz (at) *nospam* not.gonna.tell (Mateusz Viste)
Groupes : comp.lang.cDate : 14. Jun 2025, 23:22:12
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <102ksmk$evka$1@dont-email.me>
References : 1 2 3 4
User-Agent : PhoNews/3.13.3 (Android/14)
On 14.06.2025 01:31, Tim Rentsch wrote:
It isn't wrong to think of bitwise-and as masking-in (or possibly
masking-out) of certain bits, but it still isn't a modulo. A modulo
operation is what is desired;
By "different viewpoints," I meant that while you approach the problem by
applying a modulo operation to the index so it fits the array size, I tend
to think in terms of ensuring the index correctly maps to a location within
an n-bit address space. Naturally, the array should accommodate the maximum
possible index for the given address space, and that’s where the original
code fell short. And you're absolutely right that hardcoded values are
problematic, the size of the array should have been linked with the n-bits
address space expectation.
I think you have misunderstood the point of my comments. In some
cases one is confronted with a symptom that defies one's best
efforts to diagnose what is causing the symptom. Looking for known
classes of errors is another arrow in the quiver of techniques for
discovering what is causing the observed behavior.
My remark was tongue-in-cheek, but we’re clearly on the same wavelengt, no
worries. Digging into “known classes of errors” when facing bit-fiddling
gremlins is precisely how I pinpointed the root cause, and proactively
tracking other similar mistakes is on my todo. But this is an obvious,
mechanical and uninteresting subject. As I mentioned to Michael earlier,
improving code quality is a long-term, essential aspect of our work,
there’s no question about that. But alongside this continuous effort, I’m
always exploring strategies to be more defensive towards the current,
non-ideal code. In this case, my initial thought was to split the program into smaller
components that communicate via IPC. This approach would allow a faulty
component to crash with a segfault without compromising the memory of other
parts and greatly easing the debugging process. An IPC is much more
limiting and slower than a function call, so it made me wonder if it is
possible to achieve a similar level of isolation within a single program.
That question led me to post here. While there is no magic solution yet, Kaz suggested a clever workaround
using mprotect(), a compromise I’m considering applying in a few places.
Mateusz