On Mon, Dec 17, 2001 at 11:35:01AM -0800, Ken Keys wrote: > > 1) plugs the leak caused by repeated compilation; > > It works for your expression > (which used to run out of registers on the 15th compile) > and the expression I'd been testing with > (which used to run out of registers on the 5th compile). > I tested both expressions with up to 16 compiles. > > > 2) plugs any leaks discovered by compilation of a sufficiently > > complex expression (if you've found any of those); > > It worked for this artificially complex expression: > tcp[0]!=0 and (tcp[1] * tcp[2] + tcp[3] * tcp[4]) / (tcp[5] * tcp[6] + tcp[7] * >tcp[8]) + (tcp[9] * tcp[10] + tcp[11] * tcp[12]) / (tcp[13] * tcp[14] + tcp[15] * >tcp[16]) != 42 > > > 3) breaks anything you notice? > > Not that I've seen yet.
OK, I've checked that change into CVS - but haven't checked it into the 0.7 beta tree; do we want to put it in and have the beta testing run long enough to satisfy us that we haven't broken anything, or leave it out of 0.7 and put it into the next release? > I haven't looked very closely at the interpreter code, but I assumed > that no registers were kept across calls of bpf_filter(), There's currently no way to explicitly specify scratch memory locations in BPF expressions, so there's no way to specify an expression that keeps state between packets. Besides, the array used to store the scratch memory locations has automatic, not static, storage duration in the FreeBSD 3.4 "bpf_filter()" (and, as far as I know, the "bpf_filter()" in most if not all other BSDs and other FreeBSD releases). It's also automatic in the user-mode "bpf_filter()" in libpcap, and in "sk_run_filter()" in Linux 2.4.9 (and probably other 2.2 and later kernel releases), so you can't keep state between packets anyway. - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
