[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