public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jonathan Wakely <jwakely.gcc@gmail.com>
To: Antony Polukhin <antoshkka@gmail.com>
Cc: "libstdc++" <libstdc++@gcc.gnu.org>,
	gcc-patches List <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] assert that deleting by pointer to base in unique_ptr does not cause UB
Date: Wed, 22 Sep 2021 18:44:24 +0100	[thread overview]
Message-ID: <CAH6eHdQ94_SrmNM2=hQivf3_wax32aPO+N=K2d9_2ve=eq9-0w@mail.gmail.com> (raw)
In-Reply-To: <CAKqmYPZK8RHFs7SdXZKwb_gCEwrKRyJvbcgDNLh=RU0hYebh-A@mail.gmail.com>

On Wed, 22 Sept 2021 at 18:09, Antony Polukhin wrote:
>
> std::unique_ptr allows construction from std::unique_ptr of derived
> type as per [unique.ptr.single.asgn] and [unique.ptr.single.ctor]. If
> std::default_delete is used with std::unique_ptr, then after such
> construction a delete is called on a pointer to base. According to
> [expr.delete] calling a delete on a non similar object without a
> virtual destructor is an undefined behavior.
>
> This patch turns that undefined behavior into static assertions inside
> std::unique_ptr.

The undefined behaviour only happens if the destructor is actually
reached at runtime, but won't these static assertions make it
ill-formed to instantiate these members, even if the UB never happens?

For example, if you ensure that release() is called before
destruction, the undefined delete never happens.

  parent reply	other threads:[~2021-09-22 17:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-22 17:08 Antony Polukhin
2021-09-22 17:22 ` Ville Voutilainen
2021-09-22 17:49   ` Antony Polukhin
2021-09-22 17:53     ` Ville Voutilainen
2021-09-22 17:44 ` Jonathan Wakely [this message]
2021-09-22 17:56   ` Antony Polukhin
2021-09-23 10:21     ` Jonathan Wakely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAH6eHdQ94_SrmNM2=hQivf3_wax32aPO+N=K2d9_2ve=eq9-0w@mail.gmail.com' \
    --to=jwakely.gcc@gmail.com \
    --cc=antoshkka@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=libstdc++@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).