From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-140576-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 71796 invoked by alias); 25 Jul 2017 15:31:23 -0000
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
Received: (qmail 71775 invoked by uid 89); 25 Jul 2017 15:31:22 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=no version=3.3.2 spammy=H*F:D*oracle.com, mandated
X-HELO: aserp1040.oracle.com
Received: from aserp1040.oracle.com (HELO aserp1040.oracle.com) (141.146.126.69) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 25 Jul 2017 15:31:21 +0000
Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74])	by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v6PFVHRm029146	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);	Tue, 25 Jul 2017 15:31:18 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75])	by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v6PFVHNh008566	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);	Tue, 25 Jul 2017 15:31:17 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19])	by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v6PFVHAY016163;	Tue, 25 Jul 2017 15:31:17 GMT
Received: from termi.oracle.com (/10.175.202.231)	by default (Oracle Beehive Gateway v4.0)	with ESMTP ; Tue, 25 Jul 2017 08:31:16 -0700
From: jose.marchesi@oracle.com (Jose E. Marchesi)
To: Yao Qi <qiyaoltc@gmail.com>
Cc: Weimin Pan <weimin.pan@oracle.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH v4] gdb: ADI support
References: <1500424890-112103-1-git-send-email-weimin.pan@oracle.com>	<86o9s8pmyg.fsf@gmail.com>
Date: Tue, 25 Jul 2017 15:31:00 -0000
In-Reply-To: <86o9s8pmyg.fsf@gmail.com> (Yao Qi's message of "Tue, 25 Jul 2017	16:15:19 +0100")
Message-ID: <87a83sleio.fsf@oracle.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-IsSubscribed: yes
X-SW-Source: 2017-07/txt/msg00368.txt.bz2

    
    > +/* Per-process ADI stat info.  */
    > +
    > +struct sparc64_adi_info
    > +{
    > +  /* The process identifier.  */
    > +  pid_t pid;
    > +
    > +  /* The ADI stat.  */
    > +  struct adi_stat_t stat;
    > +
    > +  /* Linked list.  */
    > +  struct sparc64_adi_info *next;
    > +};
    
    Use C++ STL list.  I suggested it on the v3 review.

General question: what's wrong with using a simple linked list of
structs if that is the developer's preference, and/or it follows the
current style of the surrounding code?  (Not saying it is in this case,
that's up to Weimin to say.)

As far as I can see the usage of STL is not mandated by the GDB coding
standards (as documented in the wiki) and developers may want to avoid
them in many circumstances.