From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33691 invoked by alias); 25 May 2018 03:31:16 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 33388 invoked by uid 89); 25 May 2018 03:30:48 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 25 May 2018 03:30:47 +0000 Received: by simark.ca (Postfix, from userid 112) id 49C961F21C; Thu, 24 May 2018 23:30:29 -0400 (EDT) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id A01AD1E481; Thu, 24 May 2018 23:30:26 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 25 May 2018 05:23:00 -0000 From: Simon Marchi To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 11/10] remote_target::m_remote_state, pointer -> object (Re: [PATCH 10/10] remote: one struct remote_state per struct remote_target) In-Reply-To: <4d9a613f-b420-aa72-8561-549b383285fa@redhat.com> References: <20180516141830.16859-1-palves@redhat.com> <20180516141830.16859-11-palves@redhat.com> <4d9a613f-b420-aa72-8561-549b383285fa@redhat.com> Message-ID: X-Sender: simark@simark.ca User-Agent: Roundcube Webmail/1.3.6 X-SW-Source: 2018-05/txt/msg00657.txt.bz2 On 2018-05-24 11:53, Pedro Alves wrote: > On 05/22/2018 06:30 PM, Pedro Alves wrote: >> On 05/22/2018 04:37 AM, Simon Marchi wrote: > >>> Is there a reason not to make the remote_state object a simple field >>> of remote_target, does it have to be a pointer? You would have to >>> shuffle things around a little bit more, but it seems to work fine. >> >> Yeah, no reason other than struct remote_state not being complete yet >> when the field is defined in struct remote_target. I was thinking the >> moving would be done as follow up, to avoid even more churn mixed in >> with >> changes, very much like patch #4 started with a pointer and then patch >> #5 >> moved to objects. > Like this? Yep, looks good!