Date: Wed, 28 Dec 2005 23:37:19 +0300 From: Gleb Smirnoff <glebius@FreeBSD.org> To: Jason Evans <jasone@FreeBSD.org> Cc: freebsd-arch@FreeBSD.org Subject: Re: Adding RB_NFIND() to sys/tree.h Message-ID: <20051228203719.GD31008@FreeBSD.org> In-Reply-To: <0F813D59-3329-47EC-AB17-24CE53293357@freebsd.org> References: <0F813D59-3329-47EC-AB17-24CE53293357@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Dec 28, 2005 at 06:58:20AM -0800, Jason Evans wrote: J> [This is a slightly edited copy of email originally sent to - J> current. The only response I received was that -arch is a better J> list on which to ask for feedback on this issue.] J> J> I'd like to add RB_NFIND() to sys/tree.h, since I need it for the J> malloc implementation I've been working on. sys/tree.h comes from J> NetBSD, and up to now, the only changes we've made have been for the J> purpose of avoiding compiler warnings. J> J> RB_NFIND() is like RB_FIND(), but if an exact match isn't found, J> RB_NFIND() returns the next object in the tree (if there is one). J> Emulating RB_NFIND() with the existing RB_*() API is possible, but J> certainly not ideal. J> J> I would claim that RB_PFIND() isn't necessary, since it could be J> easily (if not quite as efficiently) emulated with RB_NFIND(), J> followed by RB_PREV(). However, there is no RB_PREV(), even though J> there is RB_NEXT(). This seems to me like an API design oversight J> (as is the omission of RB_FOREACH_REVERSE()), but it doesn't cause me J> issues, so I haven't tackled it. J> J> A patch follows (manpage changes omitted). Are there any objections J> to committing this? I see it useful, and probably will utilize soon in ipfw(4). Thanks. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051228203719.GD31008>