A "leak" normally implies something that will get worse: like, as you use this stream, the stream will slowly lose memory or something. The standard is simply saying that when the program exits the stream objects themselves--and therefore the buffers they use--will not be destroyed: but of course closing the program will destroy them... the developer who closed the bug even put "leak" in quotes as this is more an artifact of valgrind's definition of "leak" than even an "unimportant" issue in the behavior. (I want to clear this up, as I can imagine people reading what you are saying and then avoiding this feature as they are concerned that their extremely-long running program will eventually exhaust memory.)

You're right, of course. My original comment did put quotes around 'leak', but I figured someone would come along and argue a leak is a leak even if it's not going to crash your program. Oh well. :)

This isn't a "leak": a leak is a leak, and this isn't a leak... this is just something Valgrind is reporting because it could be a leak due to exhibiting a pattern indistinguishable from something that actually was leaked from the perspective of a tool that only is able to work from a dynamically maintained list of heap allocations and the event "program has now terminated". Saying this is a leak is somewhat equivalent to claiming that because the executable code itself wasn't deallocated by the program before it exited the code was "leaked": it just so happens that as an implementation detail this data structure is lazily dynamically allocated, but it should be considered a static part of the program. In a world where things Valgrind reported were "leaks" as opposed to simply "outstanding heap allocations" then I'd be happier claiming this was a bug in Valgrind than claiming that this feature of the language standard should have the word "leak" used to describe it ;P.