Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (nike.apache.org: domain of msebor@gmail.com designates
 209.85.222.190 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=pmK5ykRod8oghUayCvGs7CgxdwUcc/JT3xAJZkv++Wb3Dg8hcRwVtQr6OnJivdnzeR
         sJ1kR+u2jSZ5o6IpMw8yOMpcOvNYzo0D0PJ7Ksaec5mn4tR6y0XDr9Z1BI1BBzrtSJrE
         6IZIUZL8tIoZ2HI1+XlG76r1yDiGhiifwNLVk=
Message-ID: <4A945F3B.1070803@gmail.com>
Date: Tue, 25 Aug 2009 16:01:31 -0600
From: Martin Sebor <msebor@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3
MIME-Version: 1.0
To: dev@stdcxx.apache.org
Subject: Re: svn commit: r777603 - in /stdcxx/branches/4.2.x: etc/config/src/
 src/
References: <5DCEC29B39C9485680EB5D853D05F264@kyiv.epam.com>
In-Reply-To: <5DCEC29B39C9485680EB5D853D05F264@kyiv.epam.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 08/18/2009 02:53 AM, Farid Zaripov wrote:
>>> Actually, the MSVC 10.0 beta libc contains dtor's for std::length_error
>>> and std::logic_error only (at least in 15s configuration which I've
> tested).
>>> It is still beta for now, but I believe that these dtors will go to the
>>> release.
>>>
>>> Or should I fill the bug report to Microsoft on that issue?
>>
>> That would be great, thanks! With dtors for arbitrary C++ Standard
>> Library in their libc there's no way to build/use a third party
>> implementation such as stdcxx. Imagine one of the dtors doing
>> something to the class, e.g.:
>>
>>     class length_error: runtime_error {   // MSVC 10 definition
>>         char* data;
>>     public:
>>         virtual ~length_error () { delete[] data; }
>>         // ...
>>     }
>
>    I've filled the issue to MS, but today they resolved this issue
> with status "by design" :(

That's very bad. In stdcxx, length_error and all other exception
classes described outside of [lib.language.support] derive from
an intermediate base class, __rw::__rw_exception, which takes
care of memory management on their behalf. Failing to define
the destructors of these classes and invoking those defined in
MSVC's runtime library will, in addition to exposing programs
to the risk mentioned above, bypass the memory management
functions in stdcxx and lead to leaks.

I'm not sure I understand what they are proposing we do in the
MSVC bug report. Do you?

Martin

>
> http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Feedbac
> kID=457862
>
> Best Regards,
> Farid Zaripov
>