From owner-freebsd-security Tue Jan 25 22:44:44 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 AAA311524B for ; Tue, 25 Jan 2000 22:44:41 -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 XAA18501; Tue, 25 Jan 2000 23:44:31 -0700 (MST) Message-Id: <4.2.2.20000125234009.0404f860@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 25 Jan 2000 23:44:30 -0700 To: Matthew Dillon From: Brett Glass Subject: Re: Merged patches Cc: Warner Losh , security@FreeBSD.ORG In-Reply-To: <200001260518.VAA08275@apollo.backplane.com> References: <4.2.2.20000125133808.019fd6a0@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 10:18 PM 1/25/2000 , Matthew Dillon wrote: > No. There is a time and place for the use of a switch statement to > cover all your bases, but a *flags* field is *NOT* it. Before you assert this so emphatically, allow me to demonstrate. Again, once 4.0 is frozen, I intend to generate some patches which show what I have in mind. > Making these sorts of changes to perfectly good, working, and well > tested code is a great way to screw up said code. One can argue this about any refinement to the code -- including optimizations and changes that improve readability. I think that the code SHOULD evolve, and adding constructs which make it more readable, more efficient, easier to follow, and less susceptible to bugs is very productive. Your mileage may vary, of course. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message