stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <mse...@gmail.com>
Subject Re: svn commit: r777603 - in /stdcxx/branches/4.2.x: etc/config/src/ src/
Date Tue, 25 Aug 2009 22:01:31 GMT
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
>


Mime
View raw message