Date: Tue, 2 Jul 2002 13:47:22 -0700 (PDT) From: Julian Elischer <julian@elischer.org> To: Jonathan Lemon <jlemon@flugsvamp.com> Cc: current@freebsd.org Subject: Re: additional queue macro Message-ID: <Pine.BSF.4.21.0207021343280.97650-100000@InterJet.elischer.org> In-Reply-To: <20020702153446.A66367@prism.flugsvamp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2 Jul 2002, Jonathan Lemon wrote: > 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. yes. though the -1s in the kernel showed several bugs where threads were being handled as if they were on a list when they were no longer on that list. I'll leave it as part of teh debug code.. which brings up another question, Do you think I should remove the debug stuff when KSE becomes stable? Or maybe extend it to the other types. It was very useful in debugging KSE, showing the last 2 places that touched the linkages, but it may obscure teh source too much. thoughts anyone? > -- > 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?Pine.BSF.4.21.0207021343280.97650-100000>