[expr.new] p26 Is the matching deallocation function guaranteed to be invoked when no matching handler can be found? CWG2566
Nobody has claimed this yet.
- Dominant language
- TeX
- Stars
- 221
- Forks
- 813
- Avg merge
- 16h 4m
- Merged PRs (30d)
- 36
Description
[expr.new] p26 says
If any part of the object initialization described above terminates by throwing an exception and a suitable deallocation function can be found, the deallocation function is called to free the memory in which the object was being constructed, after which the exception continues to propagate in the context of the new-expression. If no unambiguous matching deallocation function can be found, propagating the exception does not cause the object's memory to be freed.
This implies that the deallocation function is unconditionally invoked as long as a matching version can be found. It didn't talk about whether or not a handler is necessary to be found before invoking that function.
Consider this example:
#include <iostream>
struct A{};
struct C{
void* operator new(std::size_t N,A){
std::cout<<"malloc\n";
return malloc(N);
}
void operator delete(void* ptr,A){
std::cout<<"abc\n";
free(ptr);
}
C(){
throw 0;
}
};
int main(){
auto ptr = new(A{}) C;
}
From this point, the invocation of the matching deallocation is observable, however, no implementations guarantee that function will be called. We can only find that [except.handle] p9 says:
If no matching handler is found, the function std::terminate is invoked; whether or not the stack is unwound before this invocation of std::terminate is implementation-defined
However, it is irrelevant here since stack unwinding only concerns destroying an object.
According to the implementations' behavior, we may add a condition for whether or not the matching deallocation function is called. Two suggestions here:
- If any part of the object initialization described above terminates by throwing an exception and a
suitablematching deallocation function can be found, the deallocation function is called to free the memory in which the object was being constructed if a matching handler can be found([except.handle]), after which the exception continues to propagate in the context of the new-expression.
- If any part of the object initialization described above terminates by throwing an exception and a
suitablematching deallocation function can be found, the deallocation function is called to free the memory in which the object was being constructed, after which the exception continues to propagate in the context of the new-expression. If no matching handler([except.handle]) is found, whether or not the deallocation function is called is implementation-defined.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with [expr.new] paragraph 26 and compare its wording with [except.handle] paragraph 9 and the definition of stack unwinding cited in the issue. Evaluate the two proposed interpretations against the supplied example and implementation behavior; done means resolving the ambiguity and agreeing on precise standard wording.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- compilers
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100