Known Issues
From BroWiki
Contents |
Bug with table[] of set[] initializers
The following script:
global a: table[count] of set[string] = {
[5] = set("foo", "bar"),
};
fails with "... line 2 (foo, bar): bad tag in Val::CONVERTER (types/table)".
Bug with setting defaults for sets
The following script:
type test_type: record {
myset: set[string] &default=set();
mycount: count &default=0;
};
event bro_init()
{
local local_table: table[count] of test_type;
local test_rec: test_type;
local_table[1] = test_rec;
}
fails with "... line 2 (set() and set[string]): error, &default value has inconsistent type"
--Seth 17:48, 27 May 2008 (UTC)
Switching between plain ./configure and ./configure --enable-debug requires make clean
We're not using config.h correctly, causing parts of the code to remain blind to changes to the generated config.h. This causes all kinds of build errors. The preferred way to do it is to have this at the beginning of each .cc:
#ifdef HAVE_CONFIG_H #include <config.h> #endif
—cpk 19:00, 24 January 2008 (PST)
The internal string "rendering" model needs reworking
Currently, invoking functions like cat() or fmt("%s") causes strings to have control characters and such escaped (e.g., a bare return is turned into '^' followed by 'M'). The same occurs when using "print" to write a string to a file; instead one must use write_file() to get the raw bytes.
This functionality makes manipulating large blocks of text problematic, since there are few hooks for controlling the processing. One recently introduced is the "%As" format, which turns off such rendering other than for embedded NULs.
Another problem concerns working on very large strings. For example, using the idiom "web_item = cat(web_item, new_stuff)" to iteratively build up a string that holds an entire item returned in an HTTP reply results in O(N^2) run-time, which is killer when the item happens to be many MBs and is built up only a few KB at a time. One possible approach for this idiom would be an explicit append() function. However, probably much better is to change the internal representation of strings to be blocks of text chained together (or indexed via a vector of pointers, for fast access). This makes any sort of combining of strings very fast, and would fit with deferring issues of rendering until it's time to present the string in some fashion.
--Vern 18:34, 28 May 2008 (UTC)
