From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19753 invoked by alias); 29 Jan 2015 12:43:36 -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 19736 invoked by uid 89); 29 Jan 2015 12:43:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 29 Jan 2015 12:43:34 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0TChV5e017403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 29 Jan 2015 07:43:31 -0500 Received: from bordewijk.wildebeest.org (ovpn-116-48.ams2.redhat.com [10.36.116.48]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0TChTuB029722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 29 Jan 2015 07:43:30 -0500 Received: by bordewijk.wildebeest.org (Postfix, from userid 1000) id 7B0ED80B0013; Thu, 29 Jan 2015 13:43:29 +0100 (CET) Message-ID: <1422535409.4947.5.camel@bordewijk.wildebeest.org> Subject: Re: [PATCH] Merge GCC producer parsers. Allow digits in identifiers. From: Mark Wielaard To: Joel Brobecker Cc: gdb-patches@sourceware.org Date: Thu, 29 Jan 2015 16:28:00 -0000 In-Reply-To: <20150129080018.GH5193@adacore.com> References: <1422185341-20243-1-git-send-email-mjw@redhat.com> <20150129080018.GH5193@adacore.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 X-SW-Source: 2015-01/txt/msg00759.txt.bz2 On Thu, 2015-01-29 at 12:00 +0400, Joel Brobecker wrote: > Looking at the function, it seems to me that the current design of > the function is a little strange: Named "producer_is_gcc", it'd expect > the return value to be a boolean. So, if the function returned that > and had an extra parameter for getting the major, the issue would > not arise: >=20 > else if (producer_is_gcc (cu->producer, &major, &minor)) >=20 > I think you chose this approach out of consistency with > producer_is_gcc_ge_4, which is why I'm OK with the current patch. > But if I were to look into this, what I would do replace the two > calls to this function with calls to your new function. >=20 > I might also allow major/minor to be NULL to spare users the need > to create variables that they will not need afterwards. >=20 > So, to sumarize, push as is, and then let's clean this up (you don't > have to do the cleanup, if you don't want to, but let me know if you > pass, as I'd like to take over if you do). Thanks, I pushed as is. You observations are correct. I'll refactor this as you suggest in a separate patch.