bifcl: Rename Bro to Zeek

This commit is contained in:
Daniel Thayer 2019-05-16 23:51:10 -05:00 committed by Tim Wojtulewicz
parent 3b8932ff01
commit 3ce42f2f35
3 changed files with 12 additions and 12 deletions

View file

@ -1,19 +1,19 @@
.. _Bro: https://bro.org
.. _Zeek: https://www.zeek.org
================
Bro BIF Compiler
================
=================
Zeek BIF Compiler
=================
The ``bifcl`` program simply takes a ``.bif`` file as input and
generates C++ header/source files along with a ``.zeek`` script
that all-together provide the declaration and implementation of Bro_
that all-together provide the declaration and implementation of Zeek_
Built-In-Functions (BIFs), which can then be compiled and shipped
as part of a Bro plugin.
as part of a Zeek plugin.
A BIF allows one to write arbitrary C++ code and access it via a
function call inside a Bro script. In this way, they can also be
used to access parts of Bro's internal C++ API that aren't already
function call inside a Zeek script. In this way, they can also be
used to access parts of Zeek's internal C++ API that aren't already
exposed via their own BIFs.
At the moment, learning the format of a ``.bif`` file is likely easiest
by just taking a look at the ``.bif`` files inside the Bro source-tree.
by just taking a look at the ``.bif`` files inside the Zeek source-tree.

View file

@ -105,7 +105,7 @@ HEX [0-9a-fA-F]+
/*
Hacky way to pass along arbitrary attribute expressions since the BIF parser
has little understanding of valid Bro expressions. With this pattern, the
has little understanding of valid Zeek expressions. With this pattern, the
attribute expression should stop when it reaches another attribute, another
function argument, or the end of the function declaration.
*/

View file

@ -337,7 +337,7 @@ module_def: TOK_MODULE opt_ws TOK_ID opt_ws ';'
// the type. One still has to define the type in bro.init.
// Would be nice, if we could just define the record type here
// and then copy to the .bif.zeek file, but type declarations in
// Bro can be quite powerful. Don't know whether it's worth it
// Zeek can be quite powerful. Don't know whether it's worth it
// extend the bif-language to be able to handle that all....
// Or we just support a simple form of record type definitions
// TODO: add other types (tables, sets)
@ -596,7 +596,7 @@ args_1: args_1 ',' opt_ws arg opt_ws opt_attr_list
;
// TODO: Migrate all other compound types to this rule. Once the BiF language
// can parse all regular Bro types, we can throw out the unnecessary
// can parse all regular Zeek types, we can throw out the unnecessary
// boilerplate typedefs for addr_set, string_set, etc.
type:
TOK_OPAQUE opt_ws TOK_OF opt_ws TOK_ID