The current implementation of bro-cut is too slow when processing large log files (takes more than a minute to process a single log file a few hundred MB in size). Justin Azoff rewrote bro-cut in C and found that it runs an order of magnitude faster. Another benefit of a C version of bro-cut is that we will no longer depend on gawk for anything (and some of Bro's supported platforms do not include gawk by default).
Why a static array with local code to resize instead of using something like std::vector? Is it a requirement that bro-cut be C and not C++?
The current implementation can be compiled with a C++ compiler (and it works), so I guess it's already C++.
I noticed a regression compared to the awk-version: the C bro-cut cannot handle more than one time column when converting to readable output. The branch topic/robin/ticket1215-merge has a test case in bro-cut/multiple-times.test. Might be a bit painful to fix, but I think we should ...
In branch topic/dnthayer/ticket1215, I've made the following changes:
1) bro-cut now handles time conversion for multiple time columns in a log file (and there is a new test case),
2) bro-cut no longer has a hard-coded limit on the number of columns that it can handle,
3) all tests now pass on OS X (previously, some were failing due to strftime("%z") behavior on OS X)
Just an FYI: I've added a job to Jenkins to run the bro-aux test suite, so bro-cut is now being regression tested automatically.