Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: Memory protection between compilation units?
Date: Fri, 13 Jun 2025 16:31:26 -0700
Organization: A noiseless patient Spider
Lines: 49
Message-ID: <86o6urp6b5.fsf@linuxsc.com>
References: <20250611153239.6bc43323@mateusz> <86wm9hp0u2.fsf@linuxsc.com> <20250613085927.7b7cb344@mateusz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Sat, 14 Jun 2025 01:31:30 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a9edd55b5a0bee1215b4bf0a80e1da53";
	logging-data="3942197"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/itfP1aaHQbaOGVcP3YM9eHuJ6Qg8V04M="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:PwQfp05fXUF8KJisZX8a/tT3Zx4=
	sha1:z+xZop10GWPqDtj1SNW2wmSt4ZQ=

Mateusz Viste <mateusz@x.invalid> writes:

> On Thu, 12 Jun 2025 06:05 Tim Rentsch wrote:
>
>> The code in question shows several classic error patterns.  In no
>> particular order:
>>
>>   * buffer overflow
>>   * off-by-one error
>
> I'd consider that one item, since one leads to another.

You shouldn't.  Even if they seem to be related in this instance,
they are distinct kinds of errors.  The code I posted to eliminate
the buffer overflow does avoid that problem but it still had an
off-by-one error.

>>   * using & to effect what is really a modulo operation
>
> You think of it as modulo, I think of it as "bits trimming".
> Essentially same operation, but different viewpoints I guess.

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;  in some cases that can be effected by
a bitwise-and, but in this case bitwise-and does the wrong thing.
The whole point is that it is NOT essentially the same operation.
It's a different operation, and in this case the wrong one.

>> I acknowledge that this response isn't exactly an answer to the
>> original question.  It does illustrate though a kind of thinking
>> that can be useful when trying to track down hard-to-find bugs.
>
> Thank you for your insightful remarks.  I completely agree - the best
> way to debug a program is to avoid the need for debugging in the first
> place. :-)  But working with a large, 15-year-old codebase that has
> seen contributions from dozens of programmers makes things a bit
> non-ideal sometimes.

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 point is that
there are several types of errors that could have been used, after
the fact, to uncover what was causing your problem here.  Taking
this approach might end up using a fair bit of time, but that time
is not wasted if it finds other potential lurking bugs, and there is
a good chance it will.