Message ID | 20221107155310.2590069-1-simon.marchi@polymtl.ca |
---|---|
State | Committed |
Commit | 70f479c6f8bf976ca680fd53d655ccec56b3f12e |
Headers |
Return-Path: <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A57B73858293 for <patchwork@sourceware.org>; Mon, 7 Nov 2022 15:53:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A57B73858293 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1667836433; bh=7xoT1ooBji0S3/WDRQqLq/qazTURfmpv68ELQeZlb6M=; h=To:Cc:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=kF71sqpdaFl3x8mf16bbykzkR9rgoB2kTRFrx+5TJLHpJNbisoaFVwEusKWMBSkMK 4DY91kgNvSaQt/nGoRsTxHob0sumsCF/aWu35QIGtLT+bwUoIHgZJBwxTEIcKqJDQS 1mqADO6E5kxrz8OjGTuUPSujNbkQKUSJQx/AH7L8= X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 3DFF5385841A for <gdb-patches@sourceware.org>; Mon, 7 Nov 2022 15:53:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3DFF5385841A Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 2A7FrB0l019839 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 7 Nov 2022 10:53:16 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 2A7FrB0l019839 Received: from simark.localdomain (unknown [217.28.27.60]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 6FD3A1E0D3; Mon, 7 Nov 2022 10:53:11 -0500 (EST) To: gdb-patches@sourceware.org Cc: Simon Marchi <simon.marchi@polymtl.ca> Subject: [PATCH 1/7] gdb: clear other.m_cached_id in frame_info_ptr's move ctor Date: Mon, 7 Nov 2022 10:53:04 -0500 Message-Id: <20221107155310.2590069-1-simon.marchi@polymtl.ca> X-Mailer: git-send-email 2.38.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Mon, 7 Nov 2022 15:53:11 +0000 X-Spam-Status: No, score=-3189.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list <gdb-patches.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=subscribe> From: Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> Reply-To: Simon Marchi <simon.marchi@polymtl.ca> Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
[1/7] gdb: clear other.m_cached_id in frame_info_ptr's move ctor
|
|
Commit Message
Simon Marchi
Nov. 7, 2022, 3:53 p.m. UTC
We do it in the move assignment operator, so I think it makes sense to do it here too for consistency. I don't think it's absolutely necessary to clear the other object's fields (in other words, copy constructor and move constructor could be the same), as there is no exclusive resource being transfered. The important thing is to leave the moved-from object in an unknown, but valid state. But still, I think that clearing the fields of the moved-from object is not a bad idea, it helps ensure we don't rely on the moved-from object after. Change-Id: Iee900ff9d25dad51d62765d694f2e01524351340 --- gdb/frame-info.h | 1 + 1 file changed, 1 insertion(+) base-commit: 240e07bd94a8da9270c57cde394f6883e43b8497
Comments
On 07/11/2022 16:53, Simon Marchi via Gdb-patches wrote: > We do it in the move assignment operator, so I think it makes sense to > do it here too for consistency. I don't think it's absolutely necessary > to clear the other object's fields (in other words, copy constructor and > move constructor could be the same), as there is no exclusive resource > being transfered. The important thing is to leave the moved-from object > in an unknown, but valid state. But still, I think that clearing the > fields of the moved-from object is not a bad idea, it helps ensure we > don't rely on the moved-from object after. > > Change-Id: Iee900ff9d25dad51d62765d694f2e01524351340 Seems obvious enough. Reviewed-By: Bruno Larsen <blarsen@redhat.com>
diff --git a/gdb/frame-info.h b/gdb/frame-info.h index 665f4bdae3bf..7159f82b1962 100644 --- a/gdb/frame-info.h +++ b/gdb/frame-info.h @@ -71,6 +71,7 @@ class frame_info_ptr : public intrusive_list_node<frame_info_ptr> : m_ptr (other.m_ptr), m_cached_id (other.m_cached_id) { other.m_ptr = nullptr; + other.m_cached_id = null_frame_id; frame_list.push_back (*this); }