Date: Thu, 9 Dec 2004 16:19:58 -0800 From: Brooks Davis <brooks@one-eyed-alien.net> To: Luigi Rizzo <rizzo@icir.org> Cc: ipfw@freebsd.org Subject: Re: strncmp usage in ipfw Message-ID: <20041210001958.GA8377@odin.ac.hmc.edu> In-Reply-To: <20041209150821.B5606@xorpc.icir.org> References: <20041129192514.GA7331@odin.ac.hmc.edu> <20041130041932.B91746@xorpc.icir.org> <20041209215319.GA12303@odin.ac.hmc.edu> <20041209150821.B5606@xorpc.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 09, 2004 at 03:08:21PM -0800, Luigi Rizzo wrote: > the plan is fine with me. > i wonder if one couldn't temporarily replace strncmp with a wrapper that > does behave as strncmp, but issues a warning in those cases where > the results would be ambiguous. > At least in this way one could tell if there is a problem > anywhere before removing it. That would be easy enough. We could just ship 6.x that way and switch to only using explicit abbreviations in 7.x giving us a nice deprecation schedule without too much maintenance hassle. -- Brooks > On Thu, Dec 09, 2004 at 01:53:19PM -0800, Brooks Davis wrote: > > On Tue, Nov 30, 2004 at 04:19:32AM -0800, Luigi Rizzo wrote: > > > i believe the original, old ipfw code used strncmp() to allow for > > > abbreviations. When i rewrote ipfw2 i did not feel like removing > > > the feature for fear of introducing backward compatibility problems > > > with existing files. However I agree that this introduces a > > > maintainability nightmare and i believe we should move to strcmp(), > > > especially given that with ipfw2 new option names are coming out > > > quite frequently. > >=20 > > OK, that makes sense. > >=20 > > I'd like to propose the following plan: > >=20 > > - Disallow new strncmp instances in all branches. > >=20 > > - remove strncmp usage in HEAD with the intention of explicitly adding > > back needed abbreviations when those abbreviations are both: > > - sane (no single letter appreviations, reasionable edit distance > > from other options, either obvious shorthand or reasionbly mnemon= ic). > > - actually used be someone (this is key, espeicaly since there are > > hundreds of possiable values and this isn't a documented > > feature as far as I can tell.) > >=20 > > If need be we could implement a more complex stratigy for deprecation > > where we use a new matching function and warn about short matches, but > > I'm not sure that's necessicary. > >=20 > > -- Brooks >=20 --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBuOuuXY6L6fI4GtQRAn8vAKCAKTs+T15UmiTTKGh0YEGCUVXIpACg1SxI A24pi0CLKRYBh5u4h50sLrs= =oJtq -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041210001958.GA8377>