Date: Thu, 4 Jul 2002 15:24:21 -0400 (EDT) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Julian Elischer <julian@elischer.org> Cc: FreeBSD current users <current@FreeBSD.ORG> Subject: Re: additional queue macro Message-ID: <Pine.GSO.4.10.10207041509500.23083-100000@pcnet1.pcnet.com> In-Reply-To: <Pine.BSF.4.21.0207041130240.6975-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 4 Jul 2002, Julian Elischer wrote: > > On Thu, 4 Jul 2002, Daniel Eischen wrote: > > > On Thu, 4 Jul 2002, Julian Elischer wrote: > > > > > 2/ > > > We could add a new macro/method that is slightly less efficient than the > > > current FOREACH macros, but allows element removal. > > > Exisiting methods would no change. > > > > As wollman pointed out, we already assume that it is safe to > > remove elements using the existing macros. Adding another > > interface to do the same thing kinda imples that existing > > behaviour may change. As proposed though, the new macros > > would not only allow removals, but also modification of > > the removed element while still walking the list. These might > > be useful. > > > > In this rare case Garrett was wrong. Only He assumed that. I assumed that also, and libc_r currently assumes that. Perhaps I am in the minority, but maybe there are more reliances on this than you think? Anyways, I don't have a problem transitioning to another set of macros when they are provided. -- Dan Eischen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10207041509500.23083-100000>