define a variable name based on string in bro

Hi all,

I am trying to auto generate a variable name dynamically.

For example, I want to create a test_i variable were i is a digit, that var will be used as the name of a set :

event bro_init()
{

for (i in set(1,3,5,7))
{

local fmt(“test_%s”,i): set[string] = {“one”,“two”,“three”};

}
}

event bro_done()
{
for (i in set(1,3,5,7))
{
print “one” in fmt(“test_%s”,i);
}
}

The above does not work, so is there any command in bro language that could transform a string into a variable ?

Thanks

B

I am trying to auto generate a variable name dynamically.
...
The above does not work, so is there any command in bro language that could
transform a string into a variable ?

Seems what you're looking for is a string indexed table:
https://www.bro.org/sphinx-git/scripting/index.html#id12

Jan

Hi Jan,

Thank you, but I fail to see what it is your speaking of in the link ?

Do you mean that each element in the table is a variable ?

In that case, writing\reading from this table will have complexity of O(n), right ?

Thanks again

B

Thank you, but I fail to see what it is your speaking of in the link ?
Do you mean that each element in the table is a variable ?

Exactly.

In that case, writing\reading from this table will have complexity of O(n),
right ?

No, it should be O(1) on average, see
Types — Bro 2.6.1 documentation.

I hope this helps,
Jan

Hi Jan,

I wonder if O(1) is the case for reading from a table as well ?

If so, what would be the benefit of using a bloom filter ?

Thanks

B

I wonder if O(1) is the case for reading from a table as well ?
If so, what would be the benefit of using a bloom filter ?

Roughly said: You cannot store the actual data in a bloom filter. It is
a probabilistic data structure for membership testing only. Compared to
hash tables, bloom filters are very small and constant in space.

Jan

So testing if an element was seen before using a bloom filter has the same complexity as checking if its in a table ?

Thanks

B

So testing if an element was seen before using a bloom filter has the same
complexity as checking if its in a table ?

It is a different tradeoff: The worst case for a hash table would be a
lookup that takes O(n). The "worst case" for a bloom filter would be a
match although the tested element was not added to the filter.

Have a look at Hash table - Wikipedia and
Bloom filter - Wikipedia for more details about these
data structures.

Jan

It is a different tradeoff: The worst case for a hash table would be a
lookup that takes O(n).

While that's indeed the worst case, note that Bro uses randomized universal
hash functions, so in practice you should never see such a run-time, even
for maliciously crafted inputs.

    Vern