Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Mateusz Viste <mateusz@not.gonna.tell>
Newsgroups: comp.lang.c
Subject: Re: Memory protection between compilation units?
Date: Sat, 14 Jun 2025 22:22:12 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 43
Message-ID: <102ksmk$evka$1@dont-email.me>
References: <20250611153239.6bc43323@mateusz> <86wm9hp0u2.fsf@linuxsc.com>
 <20250613085927.7b7cb344@mateusz> <86o6urp6b5.fsf@linuxsc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 15 Jun 2025 00:22:13 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="984d9a336a3eac459292df97dfa674dd";
	logging-data="491146"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19RDAjLR9IXQXfSSGF3SSuw"
User-Agent: PhoNews/3.13.3 (Android/14)
Cancel-Lock: sha1:IjSOxps/Sr9ObU4YhkuRkL6pWDA=
In-Reply-To: <86o6urp6b5.fsf@linuxsc.com>

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