[Bro] Bro install problems on linux

[Christian Kreibich]

On Fri, 2005-08-26 at 10:01 -0700, Martin Casado wrote:
> >
> >
> >
> >Here is some example output, it's like this for alot of files though.
> >
> >g++ -DHAVE_CONFIG_H -I. -I. -I..  -I. -I../src -I. -I.. -Ilibedit 
> >-I../linux-include -I../aux/libpcap-0.7.2 -O -g   -g -c -o main.o
> >`test -f main.cc || echo './'`main.cc
> >In file included from DNS_Mgr.h:28,
> >                 from main.cc:42:
> >EventHandler.h: In member function `void
> >EventHandler::SourceIDList::insert(SourceID)':
> >EventHandler.h:53: warning: cast to pointer from integer of different size
> >EventHandler.h: In member function `void
> >EventHandler::SourceIDList::sortedinsert(SourceID, int (*)(const
> >void*, const void*))':
> >EventHandler.h:53: warning: cast to pointer from integer of different size
> >EventHandler.h: In member function `void
> >EventHandler::SourceIDList::append(SourceID)':
> >EventHandler.h:53: warning: cast to pointer from integer of different size
> >EventHandler.h: In member function `SourceID

Thanks for the output, Charles (and Martin Arlitt, who sent me output
off-line).

>  Unless I'm missing something, this does look broken.  Here are the 
> snippets from the post-processed translation unit
> of EventHandler.h:
> 
>  typedef void* ent;
>  typedef uint32 SourceID;
>  struct SourceIDList : BaseList { void insert(SourceID a) { 
> BaseList::insert(ent(a)); }
> 
>  Needless to say, on a 64 bit architecture casting a 32bit into to a 
> 64bit value is a mistake.

Yeah. The problem is the hard-coded difference between lists of
instances of types (cf. List macros) and lists of pointers to instances
(cf. PList macros). Here the former is used, which breaks on 64-bit
architectures. Luckily List is used very rarely, I can only find 

  declare(List,int) in CCL.h
  declare(List, SourceID) in EventHandler.h

I presume it's somewhat tedious to change the code from List to PList
since it'll involve rethinking allocation/deallocation of container
elements, but it's the only solution I can think of. Mhm. Unless we
throw out the macro containers and switch to STL ones. What's your take
on this Vern?

>  I'm assuming this code was written before templates became practical in a
> performance sensitive environment.  Perhaps its time for an upgrade?

Fwiw, I'd like to see the self-implemented containers go as well. 

Cheers,
Christian.
-- 
________________________________________________________________________
                                          http://www.cl.cam.ac.uk/~cpk25
                                                    http://www.whoop.org