Re: PATCH: Remove unnecessary zero-initializations

[Daniel Jacobowitz <drow@mvista.com>]

On Mon, Nov 11, 2002 at 01:16:40PM -0800, Felix Lee wrote:
> Daniel Jacobowitz <drow@mvista.com>:
> > 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