[PATCH] Add comments to explain when a stream is freed by, __libc_freeres().

[Florian Weimer]

* Andreas Schwab:

> On Mai 26 2020, Florian Weimer wrote:
>
>> How can it be?  It's not an observable effect.  No user code runs after
>> this point, so what difference does it make?
>
> I don't understand.  You postulate a leak due to "neglected to call
> fclose", but streams are guaranteed to be closed anyway, thus there is
> no leak.

All memory is freed on process termination, so not calling free on
memory allocations does not introduce a leak, either.  Yet we expect
memory debuggers such as valgrind to report them.

__libc_freeres needs to strike a balance between what is technically
possible (in the sense that we may not be able to free all memory due to
the way the termination sequence is ordered), and also what results in
useful reports to users.  I think never reporting streams that have not
been fclose'd is less useful than reporting them.  Not calling fclose is
typically an application bug because you lose error checking, for
instance.

__libc_freeres should mostly deal with things that have been allocated
behind the user's back by glibc, and not things that the user could free
if they wanted.  Streams created by fopen etc. are definitely in the
latter category.

All this is well out of C and POSIX territory, so it does not matter
what they say about closing (given that the effect of calling fclose is
not observable anyway).

Thanks,
Florian