[Bro-Dev] #378: Test for problem with optional record fields.

[Bro Tracker]

#378: Test for problem with optional record fields.
--------------------------------+--------------------
  Reporter:  robin              |      Owner:
      Type:  Test Case Missing  |     Status:  new
  Priority:  Normal             |  Milestone:  Bro1.6
 Component:  Bro                |    Version:
Resolution:                     |   Keywords:
--------------------------------+--------------------

Comment (by jsiwek):

 This test case was still failing so I looked into it a bit.  This is the
 essential part of the bro script that triggers it:

 {{{
 type FOO: record {
     a: count;
     b: count &optional;
 };

 local set_of_foo: set[FOO] = set();

 add set_of_foo[[$a=4, $b=5]];

 print set_of_foo;
 }}}

 What happens is when the value is assigned to the set in
 `TableVal::Assign`, part of the `HashKey` computed from that `add`ed
 `RecordVal` index value takes into consideration whether the fields in the
 value's associated `RecordType` have the `&optional` attribute.  In this
 case, the hash is computed thinking there's no optional fields (due to the
 implicit/coerced typing?).  Now when using that `HashKey` to try to
 recover an item during the `print` statement, it thinks the size of the
 key is wacky because it's suddenly taking into account the `&optional`
 attribute of the `FOO` `RecordType` used as the set's index type.

 I can get everything to work if the computation and recovery both agree to
 use the set's index type like this:

 {{{
 diff --git a/src/CompHash.cc b/src/CompHash.cc
 index 605949b..9c06656 100644
 --- a/src/CompHash.cc
 +++ b/src/CompHash.cc
 @@ -169,7 +169,7 @@ char* CompositeHash::SingleValHash(int type_check,
 char* kp0,
             {
             char* kp = kp0;
             RecordVal* rv = v->AsRecordVal();
 -           RecordType* rt = v->Type()->AsRecordType();
 +           RecordType* rt = bt->AsRecordType();
             int num_fields = rt->NumFields();

             for ( int i = 0; i < num_fields; ++i )
 }}}

 But I'm wondering if before the `ComputeHash` part happens, the `add`ed
 index value's type should have already been coerced into the actual record
 type that's being used for the set, including the attributes of all the
 fields?  Because right now it looks like the type of the added value
 includes all the right fields, just not the attributes.

-- 
Ticket URL: <http://tracker.bro-ids.org/bro/ticket/378#comment:2>
Bro Tracker <http://tracker.bro-ids.org/bro>
Bro Issue Tracker