From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26098 invoked by alias); 20 Oct 2008 00:06:39 -0000 Received: (qmail 26085 invoked by uid 22791); 20 Oct 2008 00:06:38 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 20 Oct 2008 00:06:03 +0000 Received: (qmail 11229 invoked from network); 20 Oct 2008 00:06:01 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 20 Oct 2008 00:06:01 -0000 From: Pedro Alves To: Tom Tromey Subject: Re: Make GDB build with python 2.4 again. Date: Mon, 20 Oct 2008 00:06:00 -0000 User-Agent: KMail/1.9.9 Cc: "Paul Pluzhnikov" , gdb-patches@sourceware.org, archer@sourceware.org References: <200810192118.18369.pedro@codesourcery.com> <200810200017.19414.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200810200106.09981.pedro@codesourcery.com> 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: 2008-10/txt/msg00476.txt.bz2 On Monday 20 October 2008 00:40:40, Tom Tromey wrote: > >>>>> "Pedro" == Pedro Alves writes: > >> Note that in current gdb/python sources, additional changes > >> are required for python2.4 if Py_ssize_t isn't fixed as above ... > > Pedro> That looks strange, since ssize_t isn't usually the same size > Pedro> of int. > > My belief is that Py_ssize_t is a 2.5 introduction, and places using > Py_ssize_t used to use int. That is why the patch was written the way > it was. > Ok then. > >> > 2008-10-19 Pedro Alves > >> > > >> > * python/python-value.c (value_object_methods) > >> > (value_object_as_number, value_object_as_mapping): Move to bottom > >> > of file. > > Paul> Why? > > Pedro> To avoid all the forward references, so that we don't have to change > Pedro> two places whenever an interface changes, or things like these happen. > > This is an issue -- a minor one -- for three reasons. > > First, in general, it is better to commit code rearrangements and bug > fixes as separate patches. > I tend to follow that trend, as you can see by my latest commits. In this case, I wasn't that it was annoying me visually. It was either move, or add two ifdefs. :-/ Exacly the reason we should avoid forward declarations. > Finally, there is nothing to say that the preferred gdb style is to > avoid forward declarations. So, we picked a style we liked -- not > unintentionally, at least on my part, but because I like having the > "class definition" at the top, followed by method implementations, > followed by the initialization code. All the python code follows this > outline. If you look at most other cases where we use a structure holding function pointers, like e.g., target_ops instances, languages, debug info readers, you'll see that we define the code, and register the function pointers at the end of the file. For new code, we should try avoiding them, it's just unneeded extra work to adjust them when interfaces change. > > I'll look at moving this change to the python branch tomorrow (unless > someone gets there first). If you want all the forward declarations > removed from the python code, please let me know, and I'll implement > that on the branch as well. I'd prefer that similar new code avoids forward declarations, yes. However, I'm also fine with reverting my last change, and applying Paul's if that's less work for you. Heck, that's why we use a revision control system. -- Pedro Alves