[Bro-Dev] attributes & named types

Vlad Grigorescu vlad at es.net
Sat Nov 3 14:00:36 PDT 2018

To better understand the existing behavior, here's the commit that
introduced this (specifically with regards to conn_id):

> The &log keyword now operates as discussed:
>     - When associated with individual record fields, it defines them
>       as being logged.
>     - When associated with a complete record type, it defines all fields
>       to be logged.
>     - When associated with a record extension, it defines all added
>       fields to be logged.
>     Note that for nested record types, the inner fields must likewise
>     be declared with &log. Consequently, conn_id is now declared with
>     &log in bro.init.
> I think the discussion this is referring to is here:

On Sat, Nov 3, 2018 at 7:34 PM Vern Paxson <vern at corelight.com> wrote:

>         (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".

I've found myself wishing to remove an attribute recently, so this train of
thought is relevant. I had imagined something slightly different, which was
to maintain &log as it currently exists, but to also be able to explicitly
set it to T or F, e.g.:

> id: conn_id &log=F;

That would allow me to also be able to use redefs to configure whether or
not I want to log something:

> const log_conn = T &redef;
> ...
> id: conn_id &log=log_conn;

I think that if we add something like this for &log, it might make sense to
add it for other keywords too.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.icsi.berkeley.edu/pipermail/bro-dev/attachments/20181103/a6565227/attachment.html 

More information about the bro-dev mailing list