From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94329 invoked by alias); 21 Sep 2017 13:47:02 -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 94187 invoked by uid 89); 21 Sep 2017 13:47:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=contrary, Hx-languages-length:1858 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 ESMTP; Thu, 21 Sep 2017 13:47:00 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4E822C0546D1; Thu, 21 Sep 2017 13:46:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 4E822C0546D1 Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=palves@redhat.com Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id C154960469; Thu, 21 Sep 2017 13:46:56 +0000 (UTC) Subject: Re: [RFA 49/67] Constify some commands in btrace.c To: "Metzger, Markus T" , Tom Tromey , "gdb-patches@sourceware.org" References: <20170921051023.19023-1-tom@tromey.com> <20170921051023.19023-50-tom@tromey.com> <74f1184e-0d97-1082-4a51-3ae99c55717a@redhat.com> From: Pedro Alves Message-ID: <83de5929-b2f2-fbd5-effd-740c21cd2a98@redhat.com> Date: Thu, 21 Sep 2017 13: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: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-09/txt/msg00633.txt.bz2 On 09/21/2017 02:06 PM, Metzger, Markus T wrote: >> From: Pedro Alves [mailto:palves@redhat.com] > > Hello Pedro, Hi Markus! > My reason is simply to not mix different styles. > Alright, that's certainly a valid reason. My view is that declarations in the middle of blocks are desirable, and enforcing top-of-block-only consistency too strongly prevents incremental modernization a bit, since it puts the bar higher (because either everything is converted, or else nothing is). So personally I'm fine with mixed style, and I try to push for declare-at-initialization when it makes sense. > >> It's really up to you the style to use for this code as >> btrace maintainer > > That shouldn't be the case. If GDB is moving from a separate > declaration block to mixed-in declarations we should do it > everywhere. Ack. To me, if we need a simpler rationale, it could go like this: middle-of-block declaration+initialization makes sense with non-trivial types. And if we accept middle-of-block declarations with non-trivial types, then there's no good rationale for not allowing them with scalar types too. > > So please ignore my comments on declaration placement. On the contrary, it's not my intention to make your comment be ignored, rather that we all discuss this and end up on the same page. So thanks for the discussion, and really sorry if I sounded too nit picky. ----- BTW, looking at the get_context_size function in question, it seems like the 'number' variable is not used, meaning we could apply something like this: static int get_context_size (char **arg) { - char *pos; - int number; - - pos = skip_spaces (*arg); + char *pos = skip_spaces (*arg); if (!isdigit (*pos)) error (_("Expected positive number, got: %s."), pos); return strtol (pos, arg, 10); } Thanks, Pedro Alves