For some scripting I'm doing, I'm running into the problem that
attributes associated with named types don't get propagated. For
example,
type a: table[count] of count &default = 5;
global c: a;
print c[9];
complains that c[9] isn't set, instead of returning the value 5.
Having dived[*] into this and examined some potential fixes, I've identified
that the problem is that (1) the attribute "&default = 5" in the above
example gets associated with the identifier 'a' rather than with a's type,
and (2) when the parser processes the second line, early in the process 'a'
gets converted to its underlying type, with the attributes lost at that
point since, internally, BroType's do not have attributes.
This is a pain to deal with. If we simply add attributes to BroType's and
for statements like the first line associate the attributes with the type,
then a sequence like:
type a: table[count] of count &default = 5;
type b: a &read_expire = 1 min;
will wind up changing the attributes associated with 'a' even though it
really shouldn't.
I think the right solution for this is to introduce a new BroType called
a NamedType. A NamedType has an identifier, an underlying BroType, and a
set of attributes. When a NamedType is constructed, for its attributes
it combines both the explicit attributes in its declaration (like the
&read_expire for 'b' above) and the implicit (i.e., it inherits/copies the
&default from 'a').
I plan to implement this soon, so please speak up if you have thoughts.
Vern
[*] The dive also exposed some other bugs in attribute processing, which
I'll enter into the tracker shortly.
_______________________________________________
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
