[cxx-abi-dev] Clarification: behavior of __cxa_vec_delete3

[Mark Mitchell]

scott douglass wrote:

>On Wed, 2004-09-15 at 21:42, Mark Mitchell wrote:
>  
>
>>This patch to the specification attempts to clarify the behavior of 
>>_cxa_vec_delete3 by clarifying what it means to "delete the space" and 
>>also by making it clear that the deallocation function must be called 
>>even if the destructor for one of the array elements throws an 
>>exception, as required by DR 353.
>>    
>>
>
>_cxa_delete2 & __cxa_delete3 both say "If <code>dealloc</code> throws an
>exception, the result is undefined."  Does "the result is undefined"
>mean "the behavior is undefined"?
>  
>
Yes, I think so.

>Why is this?  If the destructor never throws an exception then I would
>expect any exception thrown by the deallocation function to just
>propagate.
>  
>
Yes, me too.  This is a corner case, since the standard ::operator 
delete[] is declared to throw no exceptions.  I cannot, however, find 
anything in the standard that forbids a class-specific ::operator 
delete[] from throwing exceptions.

>And, if both the destructor and deallocation function throw, should we
>do the normal thing for getting a second exception while cleaning up and
>go to std::terminate()?  DR 353 doesn't seem to give any guidance here.
>  
>
DR 353 itself does not, but I think that is the right thing to do.

It is indeed what EDG will do in this situation, as shown with the 
attached test program.

G++ 3.4.1 is inconsistent.  It does not use __cxa_delete3, but the 
inline code that it generates seems to ignore DR 353; it does not seem 
to call the deallocation function at all when the destructor throws.  
The G++ implementation of __cxa_delete3 (provided for ABI compatibility) 
does call the deallocation routine, but does not call std::terminate; 
instead, it propagates the exception thrown by the deallocation routine.

Perhaps we should just modify the generic ABI document to say:

The behavior of this function is as that required by the ISO C++ 
standard for "delete[] x", where "x" is of type "X*", provided that 
"array_address" is "x", "element_size" is "sizeof (X)", "padding_size" 
is the number of bytes in the array cookie (or zero, if there is no 
cookie), "destructor" is the address of the complete object destructor 
for "X" (but may be "NULL", if the destructor is trivial), and "dealloc" 
is the deallocation function for "X "(which may not be "NULL").

That would punt these kinds of details back to the ISO standard, rather 
than making us try to replicate them here.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark at codesourcery.com

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: test.C
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20040916/8ac93989/attachment.ksh>