From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86921 invoked by alias); 28 Mar 2017 14:47:41 -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 85524 invoked by uid 89); 28 Mar 2017 14:47:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=toward, Hx-languages-length:1841 X-HELO: mail-wm0-f42.google.com Received: from mail-wm0-f42.google.com (HELO mail-wm0-f42.google.com) (74.125.82.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 28 Mar 2017 14:47:38 +0000 Received: by mail-wm0-f42.google.com with SMTP id x124so640388wmf.0 for ; Tue, 28 Mar 2017 07:47:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=s8jKkxHTZ4h/9vH3eeW/F5e4ypw6hWzHpeP8TrdR/hE=; b=AD0641ybHN2vN3grTbzob27QysoLS7ImtIFiHWSof0zwE7x0gGhbqJHb55AiJELpP8 2CsRPs8ermORmz378hFtbQgEyaq9pySMfOK7YR8XMjJSRmhoLEY0OTI6Nlw+swQfpjqA 6ss9fWNxRuGmbJvzABcWPwIj+X8ltoADCl0Y3bX+NAAwNvYMTkitgPyLLQU68tksMlnM GcINHkyCpclscvSud8iA0WLta/VALGq5seM6t03KKSVVcfu08AIsUaeT16/oY21/ubj+ O7pjVVFUcRBsHxfbNsRwbzrEzCl/iaMjPy5M57GUgqz94dauxJwboFWHaNsZSb8Gkv9u /Eew== X-Gm-Message-State: AFeK/H1XF3ngyb+lmPEDD5ZU36bdckQqE+KuBqBDlV3SKsrevROhxuOuC1qqt66GcGt6+bKg X-Received: by 10.28.159.73 with SMTP id i70mr15074938wme.78.1490712457921; Tue, 28 Mar 2017 07:47:37 -0700 (PDT) Received: from [192.168.0.101] ([37.189.166.198]) by smtp.gmail.com with ESMTPSA id m188sm3933069wmm.7.2017.03.28.07.47.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 07:47:37 -0700 (PDT) Subject: Re: [PATCH 1/2] Add constructor and destructor to thread_info To: Yao Qi References: <1490689483-16084-1-git-send-email-yao.qi@linaro.org> <1490689483-16084-2-git-send-email-yao.qi@linaro.org> <06385391-127e-87b7-d727-7d03a23f293c@redhat.com> <86inmto5nx.fsf@gmail.com> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Tue, 28 Mar 2017 14:47:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <86inmto5nx.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-03/txt/msg00484.txt.bz2 On 03/28/2017 03:08 PM, Yao Qi wrote: >> >> etc. (and tweak "Non-zero" references to say "True" instead.) >> >> (the patch's subject just becomes "C++-fy thread_info a bit" instead.) >> > > Other thread_info fields can be changed to bool too. Yes, hence the "etc.". > Once I change > "executing" to bool, the 2nd argument of set_executing should be bool > too. I'll change them in separate patches. Thanks, TBC, I'm fine with incremental progress toward bool and with doing it opportunistically, rather than requiring targeted patches. Otherwise if we require changing everything at once, the result is that people will avoid doing it, for fear of the growing cascading work that propagating a type change everywhere tends to require. > > >>> @@ -220,7 +205,8 @@ init_thread_list (void) >>> for (tp = thread_list; tp; tp = tpnext) >>> { >>> tpnext = tp->next; >>> - free_thread (tp); >>> + delete tp; >>> + >> >> Spurious whitespace. >> > > You mean spurious newline? > Yes, sorry. >> These could all be in-class initialized like you did to the other >> fields, instead of using the explicit memset: >> >> - struct btrace_thread_info btrace; >> + struct btrace_thread_info btrace {}; >> >> - struct target_waitstatus pending_follow; >> + struct target_waitstatus pending_follow {TARGET_WAITKIND_SPURIOUS}; >> > > This will only initialize the first member of union > target_waitstatus.value to zero, so some bits of > target_waitstatus.value.related_pid is not initialized. Ah, blah, unions. Well, the result is that the remaining fields of the struct end up list->value->zero-initialized. Zero-initialization for unions means the first member is zero-initialized, and padding is initialized to zero. So I think the end result is the same anyway. Thanks, Pedro Alves