From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30015 invoked by alias); 22 Jan 2014 01:07:04 -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 30004 invoked by uid 89); 22 Jan 2014 01:07:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wg0-f47.google.com Received: from mail-wg0-f47.google.com (HELO mail-wg0-f47.google.com) (74.125.82.47) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 22 Jan 2014 01:07:02 +0000 Received: by mail-wg0-f47.google.com with SMTP id m15so8511500wgh.26 for ; Tue, 21 Jan 2014 17:06:59 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.78.141 with SMTP id b13mr21334861wjx.32.1390352819495; Tue, 21 Jan 2014 17:06:59 -0800 (PST) Received: by 10.194.17.104 with HTTP; Tue, 21 Jan 2014 17:06:59 -0800 (PST) In-Reply-To: <52DEDC0E.50201@redhat.com> References: <1385258996-26047-1-git-send-email-yao@codesourcery.com> <1385258996-26047-3-git-send-email-yao@codesourcery.com> <52DEDC0E.50201@redhat.com> Date: Wed, 22 Jan 2014 01:07:00 -0000 Message-ID: Subject: Re: [PATCH 02/11] Generalize varobj iterator From: Doug Evans To: Keith Seitz Cc: Yao Qi , "gdb-patches@sourceware.org" Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg00828.txt.bz2 On Tue, Jan 21, 2014 at 12:43 PM, Keith Seitz wrote: > [...] >> diff --git a/gdb/varobj.h b/gdb/varobj.h >> index 978d9b9..0f68311 100644 >> --- a/gdb/varobj.h >> +++ b/gdb/varobj.h >> @@ -308,6 +308,8 @@ extern int varobj_has_more (struct varobj *var, int >> to); >> >> extern int varobj_pretty_printed_p (struct varobj *var); >> >> +extern struct cleanup *varobj_ensure_python_env (struct varobj *var); >> + > > > IIRC, we are now adding documentation near declarations, too. Many are often > as simple as "See description in varobj.c." I could be wrong of course, but the rules are either: 1) Document at point of definition, and nothing at point of declaration. 2) Document at point of declaration, and add a comment at point of definition saying something along the lines of "See foo.h". ref: grep -F '/* See' *.c As for which to pick, I can argue either point, and don't impose a particular choice, as long as the choice isn't imposed on me either. doxygen can make this moot so I'm not worrying about it too much at the moment.