From 3ce42f2f35d477cb91106de491d6257d59b11c44 Mon Sep 17 00:00:00 2001 From: Daniel Thayer Date: Thu, 16 May 2019 23:51:10 -0500 Subject: [PATCH] bifcl: Rename Bro to Zeek --- tools/bifcl/README | 18 +++++++++--------- tools/bifcl/builtin-func.l | 2 +- tools/bifcl/builtin-func.y | 4 ++-- 3 files changed, 12 insertions(+), 12 deletions(-) diff --git a/tools/bifcl/README b/tools/bifcl/README index a3eff7ee57..f96c7a4451 100644 --- a/tools/bifcl/README +++ b/tools/bifcl/README @@ -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. diff --git a/tools/bifcl/builtin-func.l b/tools/bifcl/builtin-func.l index d8c1ddb750..6c834bdd66 100644 --- a/tools/bifcl/builtin-func.l +++ b/tools/bifcl/builtin-func.l @@ -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. */ diff --git a/tools/bifcl/builtin-func.y b/tools/bifcl/builtin-func.y index c2147fd540..6a17ad246e 100644 --- a/tools/bifcl/builtin-func.y +++ b/tools/bifcl/builtin-func.y @@ -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