From owner-freebsd-security Tue Jan 25 22:38:30 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 8A86014D61; Tue, 25 Jan 2000 22:38:21 -0800 (PST) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id XAA18453; Tue, 25 Jan 2000 23:38:11 -0700 (MST) Message-Id: <4.2.2.20000125232750.04074b50@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 25 Jan 2000 23:38:09 -0700 To: Don Lewis , Matthew Dillon From: Brett Glass Subject: Re: Merged patches Cc: security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG In-Reply-To: <200001260605.WAA28922@salsa.gv.tsc.tdk.com> References: <4.2.2.20000125113518.01a59100@localhost> <4.2.2.20000125095042.01a5aba0@localhost> <200001251722.KAA04527@harmony.village.org> <4.2.2.20000125113518.01a59100@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 11:05 PM 1/25/2000 , Don Lewis wrote: >A switch based on the TCP flags would be a very unnatural implementation. >For instance, most of the processing done on a packet received on an >established connection is the same whether the FIN bit is set or not. A switch statement can allow the same group of statements to be executed for more than one combination of the flags. >If the switch expression was based on the flags, then a large part of >the code would be duplicated between these two cases. It is also possible to "fall through" from one case to another. This makes the switch statement a very powerful tool for this sort of situation. It is also possible to call a common subroutine. The overhead of a fixed subroutine call is often less than that of a conditional branch on today's CPUs. > Also, the code >may do some processing on the segment, clear the SYN and/or FIN bits, >and then continue. I'd think it would be unusual -- perhaps bad form -- to alter the flags, as it would make the code harder to follow. In what situation(s) would you do this? In any event, one cannot always subsume ALL of the conditional jumps in a routine into a single switch. But one usually CAN reduce the number greatly. Matt seems skeptical, and I am sure that no one will want to change the code much before the freeze. But I'd like to take a shot at rewriting the code, using some switches instead of if statements, after the freeze. I think that it will have several major benefits: it'll make the code faster; it'll make it easier to read; and it will make it glaringly obvious if a case that should be considered has been missed. >A implementation that used a switch based on the socket state would >be somewhat more natural, but this is still not an exact fit. As >a matter of fact, if you look at the implemention, this is pretty >much what a lot of it does. > > switch (tp->t_state) { > case TCPS_LISTEN: { > ... Yes, it is true that switching on the socket state would be handy. The real power of the switch statement, however, shows when it is used to consider combinations of flags in parallel, as with the TCP option flags. Again, I see some skepticism here about whether it will really make the code faster or more readable, so as soon as 4.0 is frozen I'll generate some code that shows what I have in mind. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message