[PATCH] glibc/manual/examples: add missing free to open_memstream example

[Mark Wielaard]

Hi,

On Mon, 2025-06-23 at 17:47 -0700, Collin Funk wrote:
> However, I don't think this is necessary. It is common to not free
> memory when the program is going to just exit anyways. Here is what the
> GNU Coding Standards say [1]:
> 
>     Memory analysis tools such as valgrind can be useful, but don’t
>     complicate a program merely to avoid their false alarms. For
>     example, if memory is used until just before a process exits, don’t
>     free it simply to silence such a tool.
> 
> We can see this behavior in 'ls' for example:
> 
>     $ valgrind ls -la --human-readable 2>&1 | grep 'still reachable'
>     ==167809==    still reachable: 33,792 bytes in 217 blocks

As an valgrind hacker I of course love to see programs get a completely
clean memory behavior under valgrind memcheck if possible. :)

But I think having "still reachable" memory is indeed probably fine.
Such memory could in theory still be freed if the program had wanted
to. The program still has a pointer to it.

What is important is making sure the other categories don't show any
lost bytes/blocks, so for the above valgrind ls example it does also
show:

==822547== LEAK SUMMARY:
==822547==    definitely lost: 0 bytes in 0 blocks
==822547==    indirectly lost: 0 bytes in 0 blocks
==822547==      possibly lost: 0 bytes in 0 blocks

Those other kinds of leaks are often serious since the program itself
has lost track of such memory blocks.

And that is why I think (as others have also said) that in this
particular example there really should be a free. Because otherwise the
example will show some "definitely lost" bytes/blocks and that is not
good.

See also
https://developers.redhat.com/blog/2021/04/23/valgrind-memcheck-different-ways-to-lose-your-memory

Cheers,

Mark