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".
Comments?
Vern
_______________________________________________
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
