On Mon, 4 Aug 2025 at 14:29, Henrique de Moraes Holschuh <[email protected]> wrote: > > Em 04/08/2025 08:15, Roberto A. Foglietta escreveu: > > On Mon, 4 Aug 2025 at 13:11, Denys Vlasenko <[email protected]> > > 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- _______________________________________________ busybox mailing list [email protected] https://lists.busybox.net/mailman/listinfo/busybox
