Date: Tue, 25 Jan 2000 22:05:43 -0800 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Brett Glass <brett@lariat.org>, Matthew Dillon <dillon@apollo.backplane.com> Cc: security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Merged patches Message-ID: <200001260605.WAA28922@salsa.gv.tsc.tdk.com> In-Reply-To: <4.2.2.20000125113518.01a59100@localhost> References: <4.2.2.20000125095042.01a5aba0@localhost> <200001251722.KAA04527@harmony.village.org> <4.2.2.20000125113518.01a59100@localhost>
next in thread | previous in thread | raw e-mail | index | archive | help
Followups to -net only, please.
On Jan 25, 11:52am, Brett Glass wrote:
} Subject: Re: Merged patches
} Switches also make the code more readable and make it easy to handle
} every case. Some of the problems we're seeing in this code have been caused
} by failure to account for some combinations of the TCP option flags. The best
} way to ensure code correctness -- now and for the long term -- is to use
} a construct that makes it easy to be sure you cover all the bases! It's
} not only good style; it's good insurance.
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.
If the switch expression was based on the flags, then a large part of
the code would be duplicated between these two cases. Also, the code
may do some processing on the segment, clear the SYN and/or FIN bits,
and then continue.
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: {
...
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001260605.WAA28922>