From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17335 invoked by alias); 12 Nov 2002 21:44:13 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 17320 invoked from network); 12 Nov 2002 21:44:10 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 12 Nov 2002 21:44:10 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18BkhZ-0000XL-00; Tue, 12 Nov 2002 17:44:13 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18BiqF-0007vS-00; Tue, 12 Nov 2002 16:45:03 -0500 Date: Tue, 12 Nov 2002 13:44:00 -0000 From: Daniel Jacobowitz To: Felix Lee Cc: gdb-patches@sources.redhat.com Subject: Re: PATCH: Remove unnecessary zero-initializations Message-ID: <20021112214502.GA30080@nevyn.them.org> Mail-Followup-To: Felix Lee , gdb-patches@sources.redhat.com References: <20021111143426.GA26740@nevyn.them.org> <200211112116.gABLGeB03251@paper-wolf-solo.tigerfood.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200211112116.gABLGeB03251@paper-wolf-solo.tigerfood.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-11/txt/msg00355.txt.bz2 On Mon, Nov 11, 2002 at 01:16:40PM -0800, Felix Lee wrote: > Daniel Jacobowitz : > > Certainly it's a style issue. However, it's an awkward style issue and > > anyone implementing a target should be looking over the complete list > > of methods anyway. > > Of course. It's not about writing the target in the first > place, it's about reading it and maintaining it later. Say, > a year from now, someone adds a new method but doesn't spend > all the effort necessary to make all N targets work > correctly with the change, which is reasonable since it's > not sensible to insist that everyone be familiar with the > issues of all N targets before doing any work. Adding a method that requires changing the targets is something we try to avoid, anyway. This should only ever result in a missing feature. > Absence of an initializer is a simple indication that > someone should look at it and make sure it's ok. Putting in > a zero initializer is an easy sign for, "yes, this is ok". > > "Always initialize all members and methods" is a simple > style rule that encourages good programming discipline in a > couple ways, and if I were in charge I'd be adding all the > missing zero initializers rather than taking away the > existing ones :) The problem with this is that it requires updating all targets to remove an interface; and it requires adding NULL initializations that no one has been interested in doing to stay current. It just drifts further and further. > I'm not sure why you call it "an awkward style issue". If a > block of initializers seems long, it's because an interface > is complicated, and glossing over that by making the > initialization look simpler is counter-productive. The > correct point to attack is the interface itself, not the > places it's used. That's what this patch is leading up to. It's so that I don't need to grub through targets that couldn't possibly support this method every time that I remove a dead method. I have I believe seven of them here... In any case, as Elena said, I believe the right approach to this is to do it completely one way or another. I'm picking this way, which seems to match the past consensus and current practice. Patch committed. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer