[
https://bro-tracker.atlassian.net/browse/BIT-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15819#comment-15819
]
Jon Siwek commented on BIT-1159:
--------------------------------
{quote}
Also, where are things today with supporting constructs like
{code} global x: table[addr] of string = { [badguy.foo.com] = "uh-oh" }; {code}
where {{badguy.foo.com}} might resolve to multiple addresses? That was another
reason why Bro has support for list-based expansion in initializers.
{quote}
It should still work -- the lookup happens while parsing.
And yeah, it still relies on the list expansion in the initializer to work, but
I'm probably going to try and pass on removing the list-based expansion stuff
at least as part of this ticket.
> type checking inconsistencies
> -----------------------------
>
> Key: BIT-1159
> URL: https://bro-tracker.atlassian.net/browse/BIT-1159
> Project: Bro Issue Tracker
> Issue Type: Problem
> Components: Bro
> Affects Versions: git/master, 2.2
> Reporter: Justin Azoff
> Assignee: Jon Siwek
> Priority: Low
> Labels: language
> Attachments: signature.asc, signature.asc
>
>
> If you try to compare a count to a port directly, you get the following:
> {code}
> operands must be of the same type (1500/tcp < 2000)
> {code}
> but if you have a record, and mixup the types like so, it silently fails:
> {code}
> type PortRange: record {
> min: port &default=1/tcp;
> max: port &default=65535/tcp;
> };
> global pr = PortRange($min=1000,$max=2000);
> #CORRECT: global pr = PortRange($min=1000/tcp,$max=2000/tcp);
> event bro_init()
> {
> print (pr$min <= 1500/tcp && 1500/tcp < pr$max) ? "OK" : "NOTOK";
> }
> {code}
> {code}
> $ bro a.bro
> NOTOK
> {code}
--
This message was sent by Atlassian JIRA
(v6.2-OD-10-004-WN#6253)
_______________________________________________
bro-dev mailing list
bro-dev@bro.org
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
