Re: Minor patch

[Jim Meyering]

Paul Eggert <address@hidden> wrote:
> Charles Longeau <address@hidden> writes:
>
>> Here's a little patch about some memory leaks found with valgrind, on
>> sort, tail and uptime.

Thanks for the report, but those aren't really leaks.

> The changes that you propose will slow the programs down slightly and
> make them slightly bigger.  The changes won't save any memory, since
> the programs in question are all about to exit.
>
> Isn't there a way to pacify valgrind without adversely affecting the
> programs?

IMHO, there is no need to pacify valgrind.
It already makes it clear that those blocks of memory are not `lost'.
For example, with uptime, here's valgrind's summary:

  $ valgrind uptime /var/run/utmp
  ...
    8:37pm  up 8 days 22:45,  22 users,  load average: 0.05, 0.05, 0.06
  ==16639== 
  ==16639== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 8 from 1)
  ==16639== malloc/free: in use at exit: 24,576 bytes in 1 blocks.
  ==16639== malloc/free: 18 allocs, 17 frees, 52,298 bytes allocated.
  ==16639== For counts of detected errors, rerun with: -v
  ==16639== searching for pointers to 1 not-freed blocks.
  ==16639== checked 80,896 bytes.
  ==16639== 
  ==16639== LEAK SUMMARY:
  ==16639==    definitely lost: 0 bytes in 0 blocks.
  ==16639==      possibly lost: 0 bytes in 0 blocks.
  ==16639==    still reachable: 24,576 bytes in 1 blocks.
  ==16639==         suppressed: 0 bytes in 0 blocks.
  ==16639== Reachable blocks (those to which a pointer was found) are not shown.
  ==16639== To see them, rerun with: --show-reachable=yes

The block in question is the `still reachable' one.

I've debated for years whether to free such memory.
On one hand, it's not technically necessary, but on the other,
doing so reassures people who take the time to perform an audit.