From owner-freebsd-current Tue Jul 2 14:11: 9 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C53B637BF71 for ; Tue, 2 Jul 2002 14:10:22 -0700 (PDT) Received: from prism.flugsvamp.com (66-191-112-47.mad.wi.charter.com [66.191.112.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0E1944D50 for ; Tue, 2 Jul 2002 13:35:18 -0700 (PDT) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.6/8.11.6) id g62KYkV66884; Tue, 2 Jul 2002 15:34:46 -0500 (CDT) (envelope-from jlemon) Date: Tue, 2 Jul 2002 15:34:46 -0500 From: Jonathan Lemon To: Julian Elischer Cc: Jonathan Lemon , current@freebsd.org Subject: Re: additional queue macro Message-ID: <20020702153446.A66367@prism.flugsvamp.com> References: <20020702095402.D1020@prism.flugsvamp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 ? > > (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