When will bsnmp stop breaking -current builds

[Harti Brandt]

On Wed, 8 Mar 2006, Daniel Eischen wrote:

DE>On Wed, 8 Mar 2006, Dag-Erling [iso-8859-1] SmЬrgrav wrote:
DE>
DE>> Harti Brandt <hartmut.brandt at dlr.de> writes:
DE>> > I checked that gensnmptree does not generated these useless
DE>> > references since at least early 2001.
DE>>
DE>> The machine where I had this problem was running a two-week old
DE>> -CURRENT.
DE>
DE>Same here, give or take a few days.

This seems to be exact the time when usr.sbin/bsnmp was detached from 
world because of my misimport. This was from 2/14/2006 until 2/27/2006.

I wonder how this happens...

Ok. I think I got it. In Rev. 1.1.1.9 of gensnmptree.c I fixed a bug that 
was discovered by jasone: the flag field of struct node was not 
initialized to 0. This field contains the flags FL_GET and FL_SET. If both 
of them are zero, nothing is emitted for that node - this is what should 
happen to the nodes that reference the op_*dummy() functions. Even with 
this bug the code happend to work, because this location was 0 with 
phkmalloc. With the new malloc code the flag field contains obviously a 
non-zero value. So if you have an old gensnmptree (which may happen 
because the build of it was detached from world for some time) and a new 
malloc, you end up getting these references.

But for this to happen the build process also must use the installed 
gensnmptree (because the newly compiled one would not have this bug).

Can one of you verify that the new gensnmptree does the right thing?:

cd /usr/src/usr.sbin/bsnmpd/gensnmptree
make clean
make
cd /usr/src/contrib/bsnmp/snmpd
.../gensnmptree <tree.def
grep dymmy tree.c
rm tree.c tree.h

Replace ... by the path to the fresh gensnmptree.

I think the build process should use the new gensnmptree.

harti