* origin/topic/gregor/bif-tuning:
Refactor: BifTypePtr --> BifType
Bif const: make sure const is indeed a constant.
Support any type in bif const declaration.
Tweak for bifcl
Fix to bifcl wrt namespaces.
Enable declaration of set, vector, and table types in bifs.
Moving type declarations into its own bif file
Support namespaces / modules in bif. Checkpoint.
Support namespaces / modules in bif. Checkpoint.
Remove leftovers from removing "declare enum" from bifcl
Use namespaces for NetVar type pointers.
Remove unused and unnecessary "declare enum" from bifcl
Bif: add record type declaration.
Minor tweaks for bif language.
enum type: don't allow mixing of explicit value and auto-increment.
Add support for enum with explicit enumerator values.
Closes#403.
Revamp of const delcaration in bifs:
* Can only declare are const in the bif, but we cannot assign a value
or attribute to it. One has to do this in a policy file (bro.init)
* Type specification in bif is now mandatory
* Support any type in bifs (previously only bools were supported).
This will also help with automatic documentation generation, since all
const are now defined in the policy layer and thus can be documented
from there. The bif just gives the C++ layer easy access.
(now actually commiting all the files)
This change is actually two-fold:
a) bif's now accept module XYZ; statements and module::ID for
function, const, event, enum, etc. declartation
b) Added C++-namespaces to variables, functions, etc. that are declared
in bif but accessed from C++
This required some (lightweight) re-factoring of the C++ codes.
Note, event's don't have their own C++ namespace yet, since this
would require a rather huge re-factoring.
Compiles and passes test suite.
New namespace feature not tested yet.
Documentation to follow.
One can now declare (but not define) a record type in bif:
type <my_record_type_name> : record;
This adds the netvar glue so that the event engine knows about 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.bro file, but
type delcarations in bro 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
The type has be called <my_record_type_name> in bro.init and it will
be availabe as a RecordType * rectype_<my_record_type_name> in the event
engine.
TODO: add other types (tables, sets)
* Adding support for enums with explicit enumerator values (see doc
below) to bifcl and policy layer.
* Bifcl: remove (partially written) output files on error and
do a nice exit(1) instead of harsh abort() on parse errors.
* CMakeText: if bifcl fails, remove output files (failsafe,
in case bifcl fails to clean up after itself).
Enum description
----------------
Enum's are supported in .bif and .bro scripts.
An enum in a bif will become available in the event engine and
the policy layer.
Enums are "C-style". The first element in an enum will have a
value of 0, the next value will be 1, etc.
It is possible to assign an enumerator value to an element. If
next element does not have an explicit value, its values will be
the value of the last element + 1
Example::
type foo: enum {
BAR_A, # value will be 0
BAR_B, # value will be 1
BAR_C = 10, # value will be 10
BAR_D, # value will be 11
};
Enumerator values can only by positive integer literals.
The literals can be specified in (0x....), but not in octal (bro policy
layer limitation). So, do not use 0123 as value in bifs!
Each enumerator value can only be used once per enum (C allows
to use the same value multiple times). This makes reverse mapping from
value to name (e.g., in %s format strings) unambigious. This is enforced
in by the policy script.
Enums can be redef'ed, i.e., extended. Enumerator values will continue
to increment. If there are multiple redefs in different policy scripts,
then name <-> value mappings will obviously depend on the order in
which scripts are loaded (which might not be obvious).
Example::
redef enum foo += {
BAR_E, # value will be 12
BAR_F = 5, # value will be 5
BAR_G, # value will be 6
};
