24 Apr
2013
24 Apr
'13
6:35 p.m.
#983: Deep typing bug
---------------------+------------------------
Reporter: seth | Owner:
Type: Problem | Status: new
Priority: High | Milestone: Bro2.2
Component: Bro | Version: git/master
Keywords: |
---------------------+------------------------
This looks like an issue where the automatic typing is digging down one
layer (beyond the set to the first record) but then doesn't auto type the
record a layer deeper and gives an error. This is kind of a major
usability issue for the 2.2 release because of how the vulnerable software
version script works.
Example script:
{{{
@load frameworks/software/vulnerable
redef Software::vulnerable_versions += {
["Java"] = set([$max=[$major=1,$minor=5,$minor2=999]],
[$min=[$major=1,$minor=6],
$max=[$major=1,$minor=6,$minor2=0,$minor3=43]],
[$min=[$major=1,$minor=7],
$max=[$major=1,$minor=7,$minor2=0,$minor3=20]])
};
}}}
Gives the output:
{{{
error in ./test-vuln.bro, line 3: type error in initialization
([$max=[$major=1, $minor=5, $minor2=999]], [$min=[$major=1, $minor=6],
$max=[$major=1, $minor=6, $minor2=0, $minor3=43]], [$min=[$major=1,
$minor=7], $max=[$major=1, $minor=7, $minor2=0, $minor3=20]])
}}}
--
Ticket URL: <http://tracker.bro.org/bro/ticket/983>
Bro Tracker <http://tracker.bro.org/bro>
Bro Issue Tracker
24 Apr
24 Apr
6:41 p.m.
#983: Deep typing bug
----------------------+------------------------
Reporter: seth | Owner:
Type: Problem | Status: new
Priority: High | Milestone: Bro2.2
Component: Bro | Version: git/master
Resolution: | Keywords:
----------------------+------------------------
Description changed by seth:
Old description:
This looks like an issue where the automatic typing is
digging down one
layer (beyond the set to the first record) but then doesn't auto type the
record a layer deeper and gives an error. This is kind of a major
usability issue for the 2.2 release because of how the vulnerable
software version script works.
Example script:
{{{
@load frameworks/software/vulnerable
redef Software::vulnerable_versions += {
["Java"] = set([$max=[$major=1,$minor=5,$minor2=999]],
[$min=[$major=1,$minor=6],
$max=[$major=1,$minor=6,$minor2=0,$minor3=43]],
[$min=[$major=1,$minor=7],
$max=[$major=1,$minor=7,$minor2=0,$minor3=20]])
};
}}}
Gives the output:
{{{
error in ./test-vuln.bro, line 3: type error in initialization
([$max=[$major=1, $minor=5, $minor2=999]], [$min=[$major=1, $minor=6],
$max=[$major=1, $minor=6, $minor2=0, $minor3=43]], [$min=[$major=1,
$minor=7], $max=[$major=1, $minor=7, $minor2=0, $minor3=20]])
}}}
New description:
This looks like an issue where the automatic typing is digging down one
layer (beyond the set to the first record) but then doesn't auto type the
record a layer deeper and gives an error. This is kind of a major
usability issue for the 2.2 release because of how the vulnerable software
version script works.
Example script:
{{{
@load frameworks/software/vulnerable
redef Software::vulnerable_versions += {
["Java"] = set([$max=[$major=1,$minor=6,$minor2=0,$minor3=43]],
[$min=[$major=1,$minor=7],
$max=[$major=1,$minor=7,$minor2=0,$minor3=20]])
};
}}}
Gives the output:
{{{
error in ./test-vuln.bro, line 3: type error in initialization
([$max=[$major=1, $minor=6, $minor2=0, $minor3=43]], [$min=[$major=1,
$minor=7], $max=[$major=1, $minor=7, $minor2=0, $minor3=20]])}}}
--
--
Ticket URL: <http://tracker.bro.org/bro/ticket/983#comment:1>
Bro Tracker <http://tracker.bro.org/bro>
Bro Issue Tracker
30 Apr
30 Apr
8:48 p.m.
#983: Deep typing bug
----------------------+------------------------
Reporter: seth | Owner:
Type: Problem | Status: new
Priority: High | Milestone: Bro2.2
Component: Bro | Version: git/master
Resolution: | Keywords:
----------------------+------------------------
Comment (by jsiwek):
Replying to [ticket:983 seth]:
This looks like an issue where the automatic typing is digging down one
layer
(beyond the set to the first record) but then doesn't auto type the
record a layer deeper and gives an error.
It's less a problem with nested records as it is a problem with inlining
any record ctor as indices within a set/table ctor. E.g.:
{{{
print set([$max=5], [$min=2, $max=10]);
}}}
gives a "type error in initialization" since two different types are used
to index the set and there's not any code yet to resolve the ambiguity of
what to use for the overall type of the set. I think maybe an aggregate
record type should be used that's made from all fields of all indices, but
I've got some issues getting that to work right now.
A second problem comes from something like:
{{{
type MyRec: record {
min: count &optional;
max: count;
};
local myset: set[MyRec] = set([$max=5], [$max=2]);
}}}
Here, the set ctor is fine since the index types agree, but there's a
"type clash in assignment" since the type of the rhs doesn't match. I
think implementing coercion for non-empty tables/sets would fix this.
This is kind of a major usability issue for the 2.2
release because of
how the vulnerable software version script works.
Example script:
{{{
@load frameworks/software/vulnerable
redef Software::vulnerable_versions += {
["Java"] = set([$max=[$major=1,$minor=6,$minor2=0,$minor3=43]],
[$min=[$major=1,$minor=7],
$max=[$major=1,$minor=7,$minor2=0,$minor3=20]])
};
}}}
A workaround for now would be:
{{{
const one: Software::VulnerableVersionRange =
[$max=[$major=1,$minor=6,$minor2=0,$minor3=43]];
const two: Software::VulnerableVersionRange =
[$min=[$major=1,$minor=7],
$max=[$major=1,$minor=7,$minor2=0,$minor3=20]];
redef Software::vulnerable_versions += {
["Java"] = set(one, two)
};
}}}
--
Ticket URL: <http://tracker.bro.org/bro/ticket/983#comment:2>
Bro Tracker <http://tracker.bro.org/bro>
Bro Issue Tracker
10 May
10 May
7:38 p.m.
#983: Deep typing bug
----------------------+------------------------
Reporter: seth | Owner:
Type: Problem | Status: new
Priority: High | Milestone: Bro2.2
Component: Bro | Version: git/master
Resolution: | Keywords:
----------------------+------------------------
Comment (by jsiwek):
Would it be a reasonable solution to allow some type parameterization on
the container constructors. E.g.:
{{{
type MyRec: record {
min: count &optional;
max: count;
};
print record<MyRec>($min=7, $max=42);
print set<MyRec>([$max=5], [$min=2, $max=10]);
}}}
Otherwise, in an example like that, there's no way to implicitly type the
container/record.
For the original example Seth gave, there should be a way to infer type
from the context of the assignment, but IMO there always seems to be "just
one more case we forgot about" when it comes to automatic record/container
type coercion/promotion/inference...
If it sounds ok to add this feature to the language, does the syntax look
alright with the angle brackets before the constructor param lists?
{{{
record<Type>(...);
set<TypeList>(...);
table<[TypeList], Type>(...);
vector<Type>(...);
}}}
--
Ticket URL: <http://tracker.bro.org/bro/ticket/983#comment:3>
Bro Tracker <http://tracker.bro.org/bro>
Bro Issue Tracker
9:21 p.m.
#983: Deep typing bug
----------------------+------------------------
Reporter: seth | Owner:
Type: Problem | Status: new
Priority: High | Milestone: Bro2.2
Component: Bro | Version: git/master
Resolution: | Keywords:
----------------------+------------------------
Comment (by seth):
record<Type>(...);
set<TypeList>(...);
table<[TypeList], Type>(...);
vector<Type>(...);
Ooh… I like that.
--
Ticket URL: <http://tracker.bro.org/bro/ticket/983#comment:4>
Bro Tracker <http://tracker.bro.org/bro>
Bro Issue Tracker
12 May
12 May
5:10 a.m.
#983: Deep typing bug
----------------------+------------------------
Reporter: seth | Owner:
Type: Problem | Status: new
Priority: High | Milestone: Bro2.2
Component: Bro | Version: git/master
Resolution: | Keywords:
----------------------+------------------------
Comment (by vern):
This likewise strikes me as reasonable with the only question being the
syntax. I've lost track - has <type> syntax already been introduced? If
not, then I'm wondering if it's the right way to go here. You could
imagine at least some of these more directly mirroring the declaration
syntax, such as
{{{
vector of xyz (...)
}}}
Also, what's up with the '?' in "TypeList?" ?
--
Ticket URL: <http://tracker.bro.org/bro/ticket/983#comment:5>
Bro Tracker <http://tracker.bro.org/bro>
Bro Issue Tracker
5:11 a.m.
#983: Deep typing bug
----------------------+------------------------
Reporter: seth | Owner:
Type: Problem | Status: new
Priority: High | Milestone: Bro2.2
Component: Bro | Version: git/master
Resolution: | Keywords:
----------------------+------------------------
Comment (by vern):
(Oh I see, the '?' in TypeList appears to be from the Tracker itself)
--
Ticket URL: <http://tracker.bro.org/bro/ticket/983#comment:6>
Bro Tracker <http://tracker.bro.org/bro>
Bro Issue Tracker
13 May
13 May
5:09 p.m.
#983: Deep typing bug
----------------------+------------------------
Reporter: seth | Owner:
Type: Problem | Status: new
Priority: High | Milestone: Bro2.2
Component: Bro | Version: git/master
Resolution: | Keywords:
----------------------+------------------------
Comment (by jsiwek):
Replying to [comment:5 vern]:
I've lost track - has <type> syntax already
been introduced?
No, nothing uses that right now.
If not, then I'm wondering if it's the
right way to go here. You could
imagine at least some of these more directly
mirroring the declaration
syntax, such as
{{{
vector of xyz (...)
}}}
That works well for sets but looks awkward for table & vector (because the
ctor params seem to apply to the yield type and not the container itself):
{{{
set[TypeList](...) # looks fine
table[TypeList] of Type (...) # the ctor params seem to associate with
Type
vector of Type (...) # same thing
}}}
Then adding in a record ctor ruins it for everybody. If it were to be
`record<Type>(...)`, then it's entirely different from other ctors and we
need to add `<Type>` syntax just for that case. If it were to be
`record[Type](...)` or `record of Type (...)`, then it fits in with other
ctors, but is a greater mismatch with the way records are declared.
Any more preferences/ideas?
--
Ticket URL: <http://tracker.bro.org/bro/ticket/983#comment:7>
Bro Tracker <http://tracker.bro.org/bro>
Bro Issue Tracker
5:32 p.m.
#983: Deep typing bug
----------------------+------------------------
Reporter: seth | Owner:
Type: Problem | Status: new
Priority: High | Milestone: Bro2.2
Component: Bro | Version: git/master
Resolution: | Keywords:
----------------------+------------------------
Comment (by seth):
Any more preferences/ideas?
What if we could use named types as ctors directly?
{{{
type Foo: table[count] of string;
global data = Foo(1 => "test");
type Bar: record {
a: count;
b: string;
};
global data2 = Bar($a=1,$b="test");
}}}
I can see how that could be a little confusing, but at least the parser
could pick up on mis-use of types automatically and it's very clean to
read although it does expand on the existing potential confusion between
type ctors and functions.
The one thing I do really like about this is that I feel like a lot of the
current Bro auto typing magic (that fails in many situations) would
disappear.
--
Ticket URL: <http://tracker.bro.org/bro/ticket/983#comment:8>
Bro Tracker <http://tracker.bro.org/bro>
Bro Issue Tracker
14 May
14 May
3:21 a.m.
#983: Deep typing bug
----------------------+------------------------
Reporter: seth | Owner:
Type: Problem | Status: new
Priority: High | Milestone: Bro2.2
Component: Bro | Version: git/master
Resolution: | Keywords:
----------------------+------------------------
Comment (by robin):
The <> syntax would work well technically but it's not something we're
using yet, so I'm reluctant on that as well.
I like Seth's idea with using type names. That's indeed very readable.
Actually it *improves* readability; with the standard record ctor, [...],
it can be hard to figure out what type it eventually coerces into.
Downside is obviously that it works only for named types, but for records
that's not an issue and I think there are not that many other cases where
one actually needs it (the original case in this ticket is one, but I
don't think it's very common).
(Not sure about the "=>" syntax for tables though)
--
Ticket URL: <http://tracker.bro.org/bro/ticket/983#comment:9>
Bro Tracker <http://tracker.bro.org/bro>
Bro Issue Tracker
3:44 a.m.
#983: Deep typing bug
----------------------+------------------------
Reporter: seth | Owner:
Type: Problem | Status: new
Priority: High | Milestone: Bro2.2
Component: Bro | Version: git/master
Resolution: | Keywords:
----------------------+------------------------
Comment (by seth):
(Not sure about the "=>" syntax for
tables though)
That was an accident. I meant to use the normal table syntax. :)
--
Ticket URL: <http://tracker.bro.org/bro/ticket/983#comment:10>
Bro Tracker <http://tracker.bro.org/bro>
Bro Issue Tracker
15 May
15 May
12:09 a.m.
#983: Deep typing bug
----------------------+------------------------
Reporter: seth | Owner:
Type: Problem | Status: new
Priority: High | Milestone: Bro2.2
Component: Bro | Version: git/master
Resolution: | Keywords:
----------------------+------------------------
Comment (by jsiwek):
I like the idea of allowing ctors via named types, too.
A pitfall that came to mind was that it may result in more cases of
running in to the issue in #248 (my proposal for a fix is explained in
#327... should I flip that to a merge request? I was hesitant because
there seemed like a lot of unresolved discussion already). But that's not
really a new problem created by using named types as ctors, so I'll start
working on adding that and see if I run in to other issues doing it that
way.
--
Ticket URL: <http://tracker.bro.org/bro/ticket/983#comment:11>
Bro Tracker <http://tracker.bro.org/bro>
Bro Issue Tracker
6:32 a.m.
#983: Deep typing bug
----------------------+------------------------
Reporter: seth | Owner:
Type: Problem | Status: new
Priority: High | Milestone: Bro2.2
Component: Bro | Version: git/master
Resolution: | Keywords:
----------------------+------------------------
Comment (by vern):
Yeah, I like type names for this too.
--
Ticket URL: <http://tracker.bro.org/bro/ticket/983#comment:12>
Bro Tracker <http://tracker.bro.org/bro>
Bro Issue Tracker
30 May
30 May
6:59 p.m.
#983: Deep typing bug
----------------------+------------------------
Reporter: seth | Owner:
Type: Problem | Status: new
Priority: High | Milestone: Bro2.2
Component: Bro | Version: git/master
Resolution: | Keywords:
----------------------+------------------------
Comment (by jsiwek):
In [changeset:bcf5c41786d981b04ed62629fb8db03677f3e700/bro]:
{{{
#!CommitTicketReference repository="bro"
revision="bcf5c41786d981b04ed62629fb8db03677f3e700"
Allow named table constructors. Addresses #983.
}}}
--
Ticket URL: <http://tracker.bro.org/bro/ticket/983#comment:15>
Bro Tracker <http://tracker.bro.org/bro>
Bro Issue Tracker
6:59 p.m.
#983: Deep typing bug
----------------------+------------------------
Reporter: seth | Owner:
Type: Problem | Status: new
Priority: High | Milestone: Bro2.2
Component: Bro | Version: git/master
Resolution: | Keywords:
----------------------+------------------------
Comment (by jsiwek):
In [changeset:a66b7380b6690003c1b0f321f4f7459a8469a901/bro]:
{{{
#!CommitTicketReference repository="bro"
revision="a66b7380b6690003c1b0f321f4f7459a8469a901"
Allow named vector constructors. Addresses #983.
}}}
--
Ticket URL: <http://tracker.bro.org/bro/ticket/983#comment:16>
Bro Tracker <http://tracker.bro.org/bro>
Bro Issue Tracker
6:59 p.m.
#983: Deep typing bug
----------------------+------------------------
Reporter: seth | Owner:
Type: Problem | Status: new
Priority: High | Milestone: Bro2.2
Component: Bro | Version: git/master
Resolution: | Keywords:
----------------------+------------------------
Comment (by jsiwek):
In [changeset:b256642f273e4b53cd9520acebd3bf5b4fdde60d/bro]:
{{{
#!CommitTicketReference repository="bro"
revision="b256642f273e4b53cd9520acebd3bf5b4fdde60d"
Allow named set constructors. Addresses #983.
}}}
--
Ticket URL: <http://tracker.bro.org/bro/ticket/983#comment:14>
Bro Tracker <http://tracker.bro.org/bro>
Bro Issue Tracker
6:59 p.m.
#983: Deep typing bug
----------------------+------------------------
Reporter: seth | Owner:
Type: Problem | Status: new
Priority: High | Milestone: Bro2.2
Component: Bro | Version: git/master
Resolution: | Keywords:
----------------------+------------------------
Comment (by jsiwek):
In [changeset:a0ad87b4c2ac9c1028d7c22f231d57c5d6fa5184/bro]:
{{{
#!CommitTicketReference repository="bro"
revision="a0ad87b4c2ac9c1028d7c22f231d57c5d6fa5184"
Allow named record constructors. Addresses #983.
}}}
--
Ticket URL: <http://tracker.bro.org/bro/ticket/983#comment:13>
Bro Tracker <http://tracker.bro.org/bro>
Bro Issue Tracker
8:30 p.m.
#983: Deep typing bug
----------------------------+------------------------
Reporter: seth | Owner:
Type: Merge Request | Status: new
Priority: High | Milestone: Bro2.2
Component: Bro | Version: git/master
Resolution: | Keywords:
----------------------------+------------------------
Changes (by jsiwek):
* type: Problem => Merge Request
Comment:
Fix/workaround in `topic/jsiwek/983`.
--
Ticket URL: <http://tracker.bro.org/bro/ticket/983#comment:17>
Bro Tracker <http://tracker.bro.org/bro>
Bro Issue Tracker
3 Jun
3 Jun
5:16 a.m.
#983: Deep typing bug
----------------------------+------------------------
Reporter: seth | Owner: robin
Type: Merge Request | Status: closed
Priority: High | Milestone: Bro2.2
Component: Bro | Version: git/master
Resolution: fixed | Keywords:
----------------------------+------------------------
Changes (by robin):
* owner: => robin
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:d3d14e10cf7ce10f4bf9b8272b4c5174cfdd0cc8/bro]:
{{{
#!CommitTicketReference repository="bro"
revision="d3d14e10cf7ce10f4bf9b8272b4c5174cfdd0cc8"
Merge remote-tracking branch 'origin/topic/jsiwek/983'
Closes #983.
* origin/topic/jsiwek/983:
Add named constructor examples to docs.
Allow named vector constructors. Addresses #983.
Allow named table constructors. Addresses #983.
Improve set constructor argument coercion.
Allow named set constructors. Addresses #983.
Allow named record constructors. Addresses #983.
}}}
--
Ticket URL: <http://tracker.bro.org/bro/ticket/983#comment:18>
Bro Tracker <http://tracker.bro.org/bro>
Bro Issue Tracker
3270
days inactive
3310
days old
18 comments
1 participants
participants (1)
-
Bro Tracker