From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17709 invoked by alias); 7 May 2012 08:24:17 -0000 Received: (qmail 17680 invoked by uid 22791); 7 May 2012 08:24:12 -0000 X-SWARE-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 May 2012 08:23:59 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1SRJEb-0007WV-Mo from Maciej_Rozycki@mentor.com ; Mon, 07 May 2012 01:23:57 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 May 2012 01:23:57 -0700 Received: from [172.30.1.40] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Mon, 7 May 2012 09:23:54 +0100 Date: Mon, 07 May 2012 08:24:00 -0000 From: "Maciej W. Rozycki" To: Joel Brobecker CC: Subject: Re: [RFA/commit] procfs.c: Remove unused functions and make many functions static In-Reply-To: Message-ID: References: <1336000479-30511-1-git-send-email-brobecker@adacore.com> <20120504123512.GP15555@adacore.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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 X-SW-Source: 2012-05/txt/msg00170.txt.bz2 On Fri, 4 May 2012, Maciej W. Rozycki wrote: > > Even if the initial intention was to provide an API, I do not think > > it's a good idea to keep maintaining dead code. Making functions > > static is often a big help in figuring out the potential call sites > > (you immediately know that you do not have to grep the entire repo). > > I agree, I just raised my point for the avoidance of doubt. Also we have > a public repository these days where individual changes can be reasonably > easy to track for any code to resurrect if needed -- something that GDB > certainly did not have back in 1991. Hmm, here's a dumb question as a followup, following a situation I've just experienced -- can this stuff be needed by anything external on Solaris, similarly to some functions pulled from GDB by libthread_db.so.1 from glibc? Maciej