[Bro-Dev] attributes & named types

Vern Paxson vern at corelight.com
Tue Nov 6 13:00:06 PST 2018


Thanks a bunch for the further context & discussion.

The more I've delved into this, the more convinced I've become that we have
a basic architectural problem with attributes: they're associated with
identifiers and values, but not types ... *except* for hacky ways for
records and record fields.

My alternative implementation for type names fares a bit better with the
example you gave at http://try.bro.org/#/trybro/saved/275829 ... but still
gives counterintuitive behavior when I introduce a minor variant (I'll
spare you the details), with the problem being that a subsequent use of
&log (rather than the use when a record is declared) isn't propagated to
the record's individual fields.

I could I guess add code to do that propagation ... but testing further,
none of this fixes the original problem that I cared about, which is
to be able to declare types with &default values for tables, ala BIT-248:

	type str_tbl: table[string] of string &default="";

Here the problem is that the only opportunity to associate a &default
attribute with a table is when instantiating a table value.  It doesn't
work if str_tbl is instead used to define a record field, similar to the
lack of propagation for &log.

I think what we need to do is rethink the basic architecture/structure of
attributes.  In particular, types in general (not just named types) should
be able to have attributes associated with them.  The attributes associated
with an identifier are those associated with its type plus those directly
associated with the identifier (like &redef).

While doing this, we can also think about mechanisms for removing attributes.
I don't think the "&attr=F" approach mentioned earlier on this thread will do
the trick, since it's syntactically/semantically quite weird for attributes
that already take expressions as values, such as &default or &read_expire.

		Vern


More information about the bro-dev mailing list