SOLVED Re: Memory leak in hush with NOMMU busybox-1.37.0

[Roberto A. Foglietta]

On Mon, 4 Aug 2025 at 14:29, Henrique de Moraes Holschuh
<henrique at nic.br> wrote:
>
> Em 04/08/2025 08:15, Roberto A. Foglietta escreveu:
> > On Mon, 4 Aug 2025 at 13:11, Denys Vlasenko <vda.linux at googlemail.com> wrote:
> >> The correct fix is to specify the pointer in question as "volatile"
> >> variable, so that gcc stops making assumptions about its liveness.
> >
> > You are right as a manual, Denis.
> >
> > ...but god knows what gcc does with a volatile which is not associated
> > with a hardware I/O line. (LOL)
>
> Compilers never cared about this.  "volatile" in C is very well defined:
> it simply means every time the memory location is accessed, the compiler
> must issue a fresh read.
>

Dear Henrique, you are born for Wikipedia! (46 lines, 461 words)

> And that's *all* it does, which is quite often "not enough".  It is
> indeed a real pitfall that has claimed a lot of victims over the years.

Which translates in human language: Henrique is going to trust a
volatile-based work-around but he is expecting something more
explicit, and I agree that the extra code is worth ist foot-print (aka
increasing the bloatware index under specific conditions determined by
make config).

The memory leak is small, but some embedded system can run for decades
without a reboot. In the long run also a 4-bytes (32bit) leak can have
an impact. After all, it started to have an impact as soon as we
started to see it. There is more Zen in this "bug" than memory leak!
LOL

Best regards, R-