From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24292 invoked by alias); 13 Jun 2009 12:24:58 -0000 Received: (qmail 24280 invoked by uid 22791); 13 Jun 2009 12:24:57 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (140.186.70.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 13 Jun 2009 12:24:51 +0000 Received: from eliz by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1MFSHw-0001f4-CY; Sat, 13 Jun 2009 08:24:48 -0400 From: Eli Zaretskii To: Pedro Alves CC: gdb-patches@sourceware.org In-reply-to: <200906131250.02973.pedro@codesourcery.com> (message from Pedro Alves on Sat, 13 Jun 2009 12:50:02 +0100) Subject: Re: [commit] cleanup stale exec.{h|c} xfer_memory comments. Reply-to: Eli Zaretskii References: <200906121943.08246.pedro@codesourcery.com> <200906131250.02973.pedro@codesourcery.com> Message-Id: Date: Sat, 13 Jun 2009 12:24:00 -0000 X-IsSubscribed: yes 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: 2009-06/txt/msg00354.txt.bz2 > From: Pedro Alves > Date: Sat, 13 Jun 2009 12:50:02 +0100 > Cc: gdb-patches@sourceware.org > > The other exported functions of exec.c were > described in the header (and the ones that are new came from > target.h, that describes many function in the header too, including > the ones related to section_table_xfer_memory_partial). I thought > I'd follow suit for consistency with the surrounding code. I didn't know that exec.c describes functions in the headers. I'm traveling and have no easy access to GDB sources. I just saw that you removed the description from exec.c and added the more accurate one to exec.h. > > That's reasonable > > for data structures, but we have a lot of functions documented right > > before their source, not in the headers. I find the documentation in > > the .c files easier to use, because you don't need to consult another > > file. > > Fine with me. But if we're going to move the description of > this function, we should move all the others in exec.h too. Shall > I do this, or do you want to do it? I will be able to do that only in a few days, when I return home. So if you have time before that, please do it. Or maybe we should wait for others to chime in: this is a matter of personal preferences, and I've been burned before asking to adhere to mine. > > This is C, not C++, so the interface and the implementation are > > not separated. > > I must not understand header files then. (I've no idea why C++ > is being referenced here.) Forget it.