From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9180 invoked by alias); 30 Dec 2006 14:57:43 -0000 Received: (qmail 9170 invoked by uid 22791); 30 Dec 2006 14:57:42 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Sat, 30 Dec 2006 14:57:38 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1H0feQ-0003xC-WD; Sat, 30 Dec 2006 09:57:35 -0500 Date: Sat, 30 Dec 2006 14:57:00 -0000 From: Daniel Jacobowitz To: Vladimir Prus Cc: gdb-patches@sources.redhat.com Subject: Re: Cleanup varobj children handling Message-ID: <20061230145734.GA15107@nevyn.them.org> Mail-Followup-To: Vladimir Prus , gdb-patches@sources.redhat.com References: <200612082300.06688.ghost@cs.msu.su> <20061226161041.GD16188@nevyn.them.org> <200612262349.14988.ghost@cs.msu.su> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200612262349.14988.ghost@cs.msu.su> User-Agent: Mutt/1.5.13 (2006-08-11) 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: 2006-12/txt/msg00357.txt.bz2 On Tue, Dec 26, 2006 at 11:49:14PM +0300, Vladimir Prus wrote: > I personally find VEC_iterate to be less clear -- because it does not > correspond to any iteration pattern in any language I know. Do you insist > on using it? No, this is OK to leave alone. If you think of the integer index as opaque, it's really not that unlike a C++ iterator; since we can't make *ix work, we use two variables. > + /* If we're called when the list of children is not yet initialized, > + allocated enough elements in it. */ Allocate, not allocated - this is what we're doing, not what we've done. > + /* Push any children. Use reverse order so that first > + child is popped from the work stack first, and so > + will be added to result first. This does not > + affect correctness, just "nicer". */ "so that the first child" > + /* Child may be NULL is explicitly deleted by -var-delete. */ "if", not is. > + /* Update this variable, unless it's root, which is already > + updated. */ "unless it's a root" Otherwise OK, with a changelog entry. -- Daniel Jacobowitz CodeSourcery