From owner-cvs-all Mon Dec 31 13:40:41 2001 Delivered-To: cvs-all@freebsd.org Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by hub.freebsd.org (Postfix) with ESMTP id 19E0237B420; Mon, 31 Dec 2001 13:40:10 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011231214009.JPNR20122.rwcrmhc53.attbi.com@InterJet.elischer.org>; Mon, 31 Dec 2001 21:40:09 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA10332; Mon, 31 Dec 2001 13:38:55 -0800 (PST) Date: Mon, 31 Dec 2001 13:38:53 -0800 (PST) From: Julian Elischer To: John Baldwin Cc: Poul-Henning Kamp , cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Julian Elischer , Greg Lehey Subject: Re: cvs commit: src/share/man/man3 queue.3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG There is code depending on this all over the place (not just in FreeBSD) but it's not documented.. better to document it than to just allow it to be a guess. On Mon, 31 Dec 2001, John Baldwin wrote: > > On 30-Dec-01 Poul-Henning Kamp wrote: > > In message <20011230094936.K90696@monorchid.lemis.com>, Greg Lehey writes: > >>On Saturday, 29 December 2001 at 8:55:05 +0100, Poul-Henning Kamp wrote: > >>> In message <200112282200.fBSM0Rw61760@freefall.freebsd.org>, Julian > >>> Elischer wr > >>> ites: > >>>> julian 2001/12/28 14:00:27 PST > >>>> > >>>> Modified files: > >>>> share/man/man3 queue.3 > >>>> Log: > >>>> Document some behaviour I'm depending on. > >>>> (TAILQ_FOREACH leaves the variable NULL if there were no more to do) > >>> > >>> I don't like this. > >> > >>Do you have a reason for not liking it? > > > > Yes, I don't like statements with weird sideeffects. If julian > > wants the sideeffect, he should not use a _FOREACH() macro to hide > > the internals of the loop. Most looping constructs in C and in FreeBSD have a correct completion method. It would be more surprising to me if it DIDN'T have one than if it did. In this case, I dispute that this is just a side effect. It is an exit condition. > > > > _FOREACH() is for the plain & simple traversal of a queue(3) stucture, > > anything more should explicitly state intent. > > I would agree except for code like this: > > TAILQ_FOREACH(p, &list, p_next) > if (some_test_on(p)) > break; > if (p != NULL) { > /* Found one, now do something. */ > } This is the case I'm using it for. except I'm doing: TAILQ_FOREACH(p, &list, p_next) if (some_test_on(p)) break; if (p != NULL) { /* Found it, now do something. */ } lots of code that MAY clear p if (p == NULL) { /* didn't find it, or it was disqualified */ } > > You could work around this via a goto instead I suppose: > > TAILQ_FOREACH(p, &list, p_next) > if (some_test_on(p)) > goto found; > goto not_found > found: > /* Do something */ > not_found: > > But that's uglier IMO. Definitly. It is ALWAYS possible to do it with more complicated constructs, but "why?". > > -- > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message