Commit graph

7 commits

Author SHA1 Message Date
Robin Sommer
12139e9faf Merge remote branch 'origin/topic/gregor/bif-tuning'
* 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.
2011-02-25 15:41:56 -08:00
Gregor Maier
fdaeea0ea9 enum type: don't allow mixing of explicit value and auto-increment.
Updated enum type. New 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.

It is possible to assign an explicit value to an enum enumerator
element, or the enum type can automatically assign values. However,
the styles cannot be mixed. If automatic assignement is used, the first
element will have a value of 0, the next will have a value of 1, etc.

Enum type variables and identifiers can be formated using the "%s"
format specifier, in which case the symbolic name will be printed.
If the "%d" format specifier is used, the numerical value is
printed.

Example automatic assignment:
    type foo: enum {
        BAR_A,      # value will be 0
        BAR_B,      # value will be 1
        BAR_C,      # value will be 2
    };

Example with explicit assignment:
    type foobar: enum {
        BAR_X = 10,      # value will be 10
        BAR_Y = 23,      # value will be 23
        BAR_Z = 42,      # value will be 42
    };

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).

All these restrictions are enforced by the policy script layer and not
the bif compiler!

Enums can be redef'ed, i.e., extended. If the enum is automatic
increment assignment, then the value will continue to increment.
If the enum uses explicit assignment, then the redef need to use
explicit assignments as well.

Example 1::
    redef enum foo += {
        BAR_D,    # value will be 3
        BAR_E,    # value will be 4
        BAR_F,    # value will be 5
    };

Example 2::
    redef enum foobar += {
        BAR_W = 100,
    };
2011-02-10 13:14:24 -08:00
Gregor Maier
72454c230b Add support for enum with explicit enumerator values.
* 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
    };
2011-02-10 13:14:24 -08:00
Seth Hall
be5027c316 Merge branch 'master' into topic/seth/fix-compiler-warnings 2011-01-20 15:15:13 -05:00
Seth Hall
b7b29c6f92 Added line to expect shift/reduce errors in parse.in
This is the resolution that Gregor brought up in
December, 2010 on the bro-dev list.
2011-01-20 15:08:54 -05:00
Robin Sommer
75335b933e Removing global_attrs from parser, per #11, and also record
attributes. Both aren't used anywhere. Along with these goes some
more now unused code.

Closes #11.
2011-01-19 18:00:09 -08:00
Jon Siwek
79754bf6f8 Dropping byacc support; bison now required. 2010-11-17 20:38:32 -06:00
Renamed from src/parse.bison.y (Browse further)