[Freeciv-Dev] Re: (PR#2370) Path finding

["Raimar Falke" <rf13@xxxxxxxxxxxxxxxxx>]

On Tue, Mar 04, 2003 at 03:50:35AM -0800, Gregory Berkolaiko wrote:
> 
> On Mon, 3 Mar 2003, Raimar Falke wrote:
> 
> > On Mon, Mar 03, 2003 at 05:00:29AM -0800, Gregory Berkolaiko wrote:
> > > > > +  enum direction8 dir_to_next_pos;   /* Unsed only in struct_path */
> > > > 
> > > > It should be set to an invalid value otherwise.
> > > 
> > > Is
> > >   #ifdef DEBUG 
> > > ok with you?
> > 
> > This is ugly. And the write comes for free since this region is
> > already cached.
> 
> What do you mean already cached?

In the l1 and l2 cache.

> And now a quote:
> =============
> Jason> Moreover, spurious initialization may conceal other errors (like
> Jason> accessing invalid data) that could otherwise be more easily caught
> Jason> (by valgrind, for instance).
> 
> Raimar> Yes.
> =============

;)

If we set the direction in pf_position to a valid direction (which
would be the analog to the proposed solution in the other thread) we
would conceal other errors. If we set it to an invalid direction we
should catch invalid uses very quickly IMHO. On the other side it is
also possible to leave this value untouched and use valgrind. valgrind
however has the following disadvantages:
 - you have to install and use valgrind. compare this to simply using
 a CVS freeciv version
 - valgrind is slow
 - valgrind can be irritated by other things like that the fact that
 the variable is a global variable and as such set. This isn't the
 case here but think about a case where another part of the code wents
 insane/is buggy and overwrites certain memory regions which includes
 the pf_postion in question.

This is not an attempt to decry valgrind. It is just that this tool is
not the/a silver-bullet and people should know its shortcomings.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "Of course, someone who knows more about this will correct me if I'm
  wrong, and someone who knows less will correct me if I'm right."
    -- David Palmer (palmer@xxxxxxxxxxxxxxxxxx)