[Bro-Dev] Bif tuning / overhaul
gregor at icir.org
Wed Feb 16 11:03:25 PST 2011
> I actually like the Bif prefix, it clearly indicates where the stuff
> is coming from. But how about using "BifType" instead of "BifTypePtr".
> Types are always passed around as pointers anyway, so I don't see a
> problem with leaving that hint out, and it makes the name more
(I guess that's a leftover from an earlier version where all the
namespaces were called Bro* and BroType obviously already exists ;-)
>> + can now only declare but not define consts. You must define
>> the const in bro.init. The bif only creates the netvar glue code.
> Is the reason for this just the work it would require to implement it
> fully, or something else? Seems in principle bifcl could just as well
> generate everything, with all the definitions (for consts, types,
> etc.) being right there in the bif as well. That would be ideal as it
> would follow the rule of "having things only in one place". (I'm not
> asking you to implement it; just curious).
I agree that it would be great to be able to do all this stuff in BiF.
The reason why I haven't implemented it is indeed, that it would require
a lot of work to do it. Bro's syntax for defining types, and consts is
very rich and implementing that would require to add a good chunk of the
Bro syntax to Bifcl. We would probably have to rewrite most of the Bif
If we want that, we might want to consider using the Bro-parser and
extending it to support generation of C/C++ (basically have two modes
for the Bro-parser: BiF and script).
This would be something to keep in mind when we move towards compiling
Bro scripts (into HILTI) and/or when we think of adding "plugins" so
that analyzers can be developed externally and then loaded as a plugin.
Then BiF's could be just one such plugin.
<gregor at icir.org> <gregor at icsi.berkeley.edu>
Int. Computer Science Institute (ICSI)
1947 Center St., Ste. 600
Berkeley, CA 94704, USA
More information about the bro-dev