stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: svn commit: r553587 - /incubator/stdcxx/trunk/tests/self/0.new.cpp
Date Fri, 13 Jul 2007 14:57:26 GMT
Farid Zaripov wrote:
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com] 
>> Sent: Wednesday, July 11, 2007 10:25 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: svn commit: r553587 - 
>> /incubator/stdcxx/trunk/tests/self/0.new.cpp
>>
>> faridz@apache.org wrote:
>>> Author: faridz
>>> Date: Thu Jul  5 11:13:04 2007
>>> New Revision: 553587
>>>
>>> URL: http://svn.apache.org/viewvc?view=rev&rev=553587
>>> Log:
>>> 2007-07-05 Farid Zaripov <Farid_Zaripov@epam.com>
>>>
>>> 	* 0.new.cpp: Catch SIGSEGV signal as SIGABRT.
>> Why is this necessary?
> 
>   On MSVC operator delete[] () invoke operator delete (). So in the
> following code
> (taken from test_mismatch()):
> 
>   void* p = operator new (0);
>   operator delete[] (p);
>   operator delete (p);
> 
>   the operator delete[] (p) frees the memory and next operator delete
> (p) raises SIGSEGV.
> 
>   To continue the execution and check another testcases the SIGSEGV
> signal should be handled.

But the SIGSEGV indicates an error, while SIGABRT indicates
the expected behavior. I.e., the replacement operator delete
defined in the driver aborts when it's passed a pointer that
wasn't returned from a prior call to the matching operator
new. The operator should never segfault. Is the replacement
operator not being called?

Martin

Mime
View raw message