[Bro-Dev] attributes & named types

Vern Paxson vern at corelight.com
Sat Nov 3 12:27:13 PDT 2018

Hmmmm I've looked into this and there are some subtle issues.

First, I tried to make this work using TypeType's like I had sketched, and
it turns out to be a mess.  Too many points where a decision has to be
made whether to access the base type (what the named type points to) rather
than the TypeType itself.

I then had an Aha and realized it can instead be done in the grammar, by
associating different semantics with resolving type names depending on the
context in which they appear.  I have this working.  It's pretty simple, too.

HOWEVER: running on the test suite points up an issue I hadn't anticipated.
We have attributes associated with named types that currently aren't expected
to propagate.  One example is from share/bro/base/init-bare.bro:

	## A connection's identifying 4-tuple of endpoints and ports.
	## .. note:: It's actually a 5-tuple: the transport-layer protocol is stored as
	##    part of the port values, `orig_p` and `resp_p`, and can be extracted from
	##    them with :bro:id:`get_port_transport_proto`.
	type conn_id: record {
		orig_h: addr;   ##< The originator's IP address.
		orig_p: port;   ##< The originator's port number.
		resp_h: addr;   ##< The responder's IP address.
		resp_p: port;   ##< The responder's port number.
	} &log;

So conn_id's have &log associated with them.  I'm not sure why this was
done (maybe a question for @Seth), since previously this was a no-op.
However, with my change/fix, this now means that any use of a conn_id
automatically inherits &log.  In principle, that's consistent with the
on-the-face-of-it semantics ... but it will likely lead to significant
unwanted effects if left unaddressed.

I have a couple of thoughts regarding this:

	(1) I can go through the existing scripts and remove such attributes
	    where they currently appear.  I believe that this shouldn't have
	    any effect because previously those weren't propagated anyway;
	    their presence seems to me more a bug than anything else, but
	    maybe I'm missing something.

	(2) This makes me wonder about adding an operator to *remove* an
	    attribute if present.  For example, you could imagine wanting
	    to now do something like:

		type my_conn_info: record {
			id: conn_id -&log;

	    as a way of specifying "if conn_id's have a &log attribute,
	    I don't want to inherit it".



More information about the bro-dev mailing list