Sounds good and I like it. To be honest I'm not even sure if the behavior
is defined right now, i.e. if the later value will overwrite the first one.

Do you want to error out when two &defaults are found or overwrite the
first with the second one?


On Mon, Oct 29, 2018 at 11:56 AM Vern Paxson <v...@corelight.com> wrote:

> Attributes currently receive essentially no consistency checking.
> For example, executing this script:
>
>         global a: count
>                 &default = 10
>                 &default = 9
>                 &optional
>                 &log
>                 &add_func = function(d: double, t: time): count { return
> 3; };
>         print a;
>
> simply results in:
>
> error in /Users/vern/tmp/attr-type-check.bro, line 7: value used but not
> set (a)
>
> I'm planning to add basic consistency checking, which will look for
> (1) attributes that are repeated (which doesn't appear to be meaningful for
> any of them) and (2) attributes that don't make sense in a given context,
> like the ones listed above.
>
> I'm thinking of implementing this as an internal table of meta-attributes,
> i.e., each attribute type, like ATTR_OPTIONAL, will have its own attributes
> like whether it requires a record context, only makes sense for aggregates,
> etc.  Here are the ones that come to mind, based on looking at the
> attributes
> at https://www.bro.org/sphinx/script-reference/attributes.html with
> examples
> in parens:
>
>         applies to global variable      (&redef)
>                 to global type          (&redef)
>                 to event handler        (&priority)
>                 to record field         (&log)
>                 to indexed type         (&default)
>                 to global indexed type  (&add_func)
>                 to type with expirable entries  (&expire_func)
>                 to a file               (&rotate_interval)
>
> Any feedback?
>
>                 Vern
> _______________________________________________
> bro-dev mailing list
> bro-dev@bro.org
> http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
>
_______________________________________________
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev

Reply via email to