From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17012 invoked by alias); 4 May 2012 12:35:30 -0000 Received: (qmail 16914 invoked by uid 22791); 4 May 2012 12:35:29 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_NO X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 04 May 2012 12:35:16 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id A9B461C6AE4; Fri, 4 May 2012 08:35:15 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OgIFw4wQMUrP; Fri, 4 May 2012 08:35:15 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id A96571C65D3; Fri, 4 May 2012 08:35:14 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 3E028145616; Fri, 4 May 2012 05:35:12 -0700 (PDT) Date: Fri, 04 May 2012 12:35:00 -0000 From: Joel Brobecker To: "Maciej W. Rozycki" Cc: gdb-patches@sourceware.org Subject: Re: [RFA/commit] procfs.c: Remove unused functions and make many functions static Message-ID: <20120504123512.GP15555@adacore.com> References: <1336000479-30511-1-git-send-email-brobecker@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) 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/msg00126.txt.bz2 > I hesitated doing that in the change you must obviously have in mind > because it appeared to me that this source file wants to present a > complete API to /proc services, even if some parts are not actually > (currently) used by GDB (but may be or may have been sometime). [...] > What is unclear to me of course is whether the availability of the > complete API (if my perception is indeed correct) is relevant any longer > and why the prototypes have never been moved to a header clients could > use. 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). But the procfs.c file in particular is one file that would deserve a good cleanup (too many #ifdefs to support the various systems, and their different versions). The problem is that I'm not sure such cleanup would be worth the effort, because I don't think that the /proc interface has much future in general... Even LynxOS uses ptrace :). So, my view is that we should contain and isolate that code as much as we can. -- Joel