Subject: Re: [boost] C++ announcements coming tomorrow
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2012-11-06 05:15:28
On Tue, Nov 6, 2012 at 5:24 AM, Beman Dawes <bdawes_at_[hidden]> wrote:
> On Mon, Nov 5, 2012 at 3:22 AM, Andrey Semashev
> <andrey.semashev_at_[hidden]> wrote:
>> On November 5, 2012 6:06:42 AM "Stephan T. Lavavej"
>> <stl_at_[hidden]> wrote:
>>>
>>> [Andrey Semashev]
>>> > +1, I had reported a memory leak bug [1] to MS and had been told that
>>> > the behavior is correct as it doesn't contradict the Standard. I can't
>>> > trust the vendor that treats users this way and declares a memory leak
>>> > as a valid behavior. I doubt I will ever bother reporting any other
>>> > bugs in MSVC.
>>> > [1] The leak appeared in STL streams, if initialized multiple times.
>>> > Here's a code snippet:
>>> > https://sourceforge.net/apps/trac/boost-log/ticket/2#comment:4
>>> > I didn't keep a reference to the MS bug tracker and I can't find it now.
>>>
>>> This was Dev10#831920/Connect#518512. I can't load the Connect link
>>> anymore (it is supposed to be
>>> http://connect.microsoft.com/VisualStudio/feedback/details/518512/memory-leak-in-ostream-init
>>> and I don't know why it's broken) but I can still see the comments through
>>> Team Foundation Server. This behavior was really, truly conformant to the
>>> Standard - I was surprised too, so I had to ask P.J. Plauger for an
>>> explanation. Here are the comments:
>>
>>
>> [snip]
>>
>> Thank you Stephan for digging it out. But I still don't agree with your
>> conclusions and consider it a serious bug.
>
> If you read the standard one way and a library supplier reads it
> another way, you can file a Library Working Group issue. It may be
> that the standard needs clarification, or there is a mistake in the
> standard, or the standard is correct as written but the LWG feels the
> behavior should be changed, or whatever. Resolving this kind of issue
> is one of the functions of the standards committee.
>
> If some implementations behave one way, and some behave a different
> way, the LWG is likely to be particularly interested in pursuing the
> issue.
I've tested this with STLPort when I found the problem and with GCC
4.7 now. Both did not show the leak, so MS STL stands out. Yes, I
would like this issue to be resolved in the Standard but I don't think
I have the necessary resource to prepare and (most importantly) defend
the proposal before the committee.