cplusplus / cplusplus/draft

[expr.new] p26 Is the matching deallocation function guaranteed to be invoked when no matching handler can be found? CWG2566

Open
#5,390 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

cwg not-editorial
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 suitable matching 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 suitable matching 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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.