[Bro-Dev] BiF parsing index types
Gregor Maier
gregor at icir.org
Sat May 14 11:55:27 PDT 2011
On 5/13/11 17:46 , Robin Sommer wrote:
>> Type definitions in bro can be quite complex and one would have to
>> completely duplicate that in bif.
>
> Does bifcf really need to parse the type fully? Could it just treat
> more complex types as opaque strings and carry them through into the
> output?
I thought about that too. However the problem with treating the types as
opaque is that the parser still has to parse over them as they contain
keyword, tokens, braces, etc.
>> I could just specify the record in the BiF. Instead I have to specify
>> the record in a bro file and put a simple "type foo: record;" in the
>> BiF. Otherwise I would have had to copy all record-type-definition syntax.
>
> Likewise, would some simpler parsing rule work here that doesn't
> understand all the pieces going into the record? Haven't really
> thought this through admittedly.
This has the same problem as the types in the header, however, it might
be easier to solve: One solution might be to introduce a new kind of
brackets/paranthese so that the scanner can skip over the record
definition, e.g.,
type asdf: record @{
# opaque string comes here
@}
However, that's yet another brace-style....
(maybe one could also re-use another bracket or brace, have to look at
the bif parser for that though).
Still, one "problem" is that if there is a syntax error in the record
definition, you will only see it during Bro-runtime in the generated
.bro file. That implies that we probably have to add markers to the
generated bro-file so that a user knows where the error actually came
from. But that's more a cosmetic issue.
cu
Gregor
--
Gregor Maier
<gregor at icir.org> <gregor at icsi.berkeley.edu>
Int. Computer Science Institute (ICSI)
1947 Center St., Ste. 600
Berkeley, CA 94704, USA
http://www.icir.org/gregor/
More information about the bro-dev
mailing list