Date: Tue, 2 Jul 2002 15:34:46 -0500 From: Jonathan Lemon <jlemon@flugsvamp.com> To: Julian Elischer <julian@elischer.org> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, current@freebsd.org Subject: Re: additional queue macro Message-ID: <20020702153446.A66367@prism.flugsvamp.com> In-Reply-To: <Pine.BSF.4.21.0207021249180.97650-100000@InterJet.elischer.org> References: <20020702095402.D1020@prism.flugsvamp.com> <Pine.BSF.4.21.0207021249180.97650-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jul 02, 2002 at 12:58:24PM -0700, Julian Elischer wrote: > > On Tue, 2 Jul 2002, Jonathan Lemon wrote: > > > What do people think about adding the following macro to <sys/queue.h>? > > (I don't care much about the name, just the functionality) > > > > #define TAILQ_FOREACH_TMP(var, tmp, head, field) \ > > for ((var) = TAILQ_FIRST((head)); \ > > (var) && (((tmp) = TAILQ_NEXT((var), field)) || 1); \ > > (var) = (tmp)) > > Certainly this is moving in the right direction.. > (acknowleging the problem).. It does the job. > but if someone knows to use it then they probably also > know to use a temp variable themselves. > > It does work in that there is very little the writer can do to screw this > up. > > The question is simply "is it waranted?" > It does add complexity.. I guess it needs to be added to all > the other types as well (LIST, STAILQ etc) Well, as Garrett pointed out, the question also is, "is this correct?" It appears that the old behavior of not modifying the list pointer may actually be part of the API (although undocumented), and one way to fix the problem is to just document the behavior. Since user programs (like libc_r) may already depend on this, perhaps the most prudent choice may be to leave the original behavior alone. -- Jonathan 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?20020702153446.A66367>