another question:
it seems that I can't specify the value that my enums should have, i.e.,
I can't do a
enum { foo = 2, bar = 3 }
So, it seems that I'll have to use global const to simulate the
behavior. But the nice feature of enums is that if I print them with %s,
I get their name instead of their value. Is there any way to simulate
this (without using a table to map values->names?)
Looking a bit more at the event engine, it seems that there's no case in
which an enum is passed from the event engine to the policy layer as
part of an event. It also seems that there's no way to coerce an integer
into an enum, right (neither policy layer nor event engine).
I'm wondering whether there was a reason for not implementing that
(e.g., would break something, enums should be policy layer only). If
not, I guess my question is whether it would make sense to add it (at
some stage) as I think it would make handling of binary protocols easier.
(There seems to be one case (transport_proto) were there's interaction
in bro.bif, but it requires a lot of glue functions).
Hmm, I partially found the solution. Adding an enum in const.bif seem to
do the trick for using one enum definition in both the policy layer and
the event engine.
Also found how to coerce integer into EnumVal in the event engine (but
still don't know how to achieve this in the policy layer).
Enums with pre-assigned values still don't work though
I think I'll actually add this to the bif-language and the
bro-policy-lanague, so that one can indeed specify
enum { ASDF=4, FOO=7, BAR=0, }
in .bro and .bif files.
For completeness, Gregor & I just discussed this and the plan is to go
ahead with adding this feature at some point. (Note, the support won't
include enum<->int conversion.)
> (Note, the support won't
> include enum<->int conversion.)
Can you guys elaborate on this? I would think we dont' want implicit
conversions, but some form of explicit cast would be nice to have
both ways.
I resist adding language features/flexibility without clear use cases.
Casting enum<->int weakens type safety, so there should be a clear need
to have it anyway. So far, we don't have that. If we do, then we can
revisit it to determine whether general explicit coercion is indeed the
best way to support the need.
