From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19368 invoked by alias); 23 Jun 2014 14:57:42 -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 19284 invoked by uid 89); 23 Jun 2014 14:57:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mtaout27.012.net.il Received: from mtaout27.012.net.il (HELO mtaout27.012.net.il) (80.179.55.183) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 23 Jun 2014 14:57:28 +0000 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0N7M00F00MJ2TJ00@mtaout27.012.net.il> for gdb-patches@sourceware.org; Mon, 23 Jun 2014 17:54:10 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N7M00D6UMQ9N530@mtaout27.012.net.il>; Mon, 23 Jun 2014 17:54:10 +0300 (IDT) Date: Mon, 23 Jun 2014 14:57:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH v2 10/14] make dwarf_expr_frame_base_1 public In-reply-to: <20140623081815.GA16611@blade.nx> To: Gary Benson Cc: dje@google.com, tromey@redhat.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83ha3bsmgf.fsf@gnu.org> References: <1403279874-23781-1-git-send-email-tromey@redhat.com> <1403279874-23781-11-git-send-email-tromey@redhat.com> <20140623081815.GA16611@blade.nx> X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg00817.txt.bz2 > Date: Mon, 23 Jun 2014 09:18:15 +0100 > From: Gary Benson > Cc: Tom Tromey , gdb-patches > > > > 2014-06-20 Tom Tromey > > > > > > * dwarf2loc.h (dwarf_expr_frame_base_1): Declare. > > > * dwarf2loc.c (dwarf_expr_frame_base_1): Now public. > > > > [apologies for the repeat ... curse you gmail ...] > > > > Can you remove the _1? > > (renaming it as needed) > > I see the non _1 version is also static, so some reasonable renaming > > (perhaps of both) should be simple enough. > > Is there some convention about what "_1" means in a function name? In most, if not all, cases I saw those are internal subroutines of the sans-_1 peers.