From owner-freebsd-current  Mon Jan  6 17:25:39 1997
Return-Path: <owner-current>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id RAA18559
          for current-outgoing; Mon, 6 Jan 1997 17:25:39 -0800 (PST)
Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211])
          by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id RAA18544;
          Mon, 6 Jan 1997 17:25:32 -0800 (PST)
Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA13256; Mon, 6 Jan 1997 18:15:51 -0700
From: Terry Lambert <terry@lambert.org>
Message-Id: <199701070115.SAA13256@phaeton.artisoft.com>
Subject: Re: <sys/queue.h> potential for panic
To: dg@root.com
Date: Mon, 6 Jan 1997 18:15:51 -0700 (MST)
Cc: phk@freebsd.org, current@freebsd.org
In-Reply-To: <199701011422.GAA10526@root.com> from "David Greenman" at Jan 1, 97 06:22:49 am
X-Mailer: ELM [version 2.4 PL24]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> >TAILQ_REMOVE and STAILQ_REMOVE would panic with a zero dereference
> >if you tried to remove something not on the queue.
> >
> >Wouldn't it make sense to avoid that, or would the overhead be considered
> >prohibitive ?
> 
>    It would be a software error if multiple TAILQ_REMOVEs occurred (in just
> the same way that multiple frees are a bug), so the condition must be caught.
> I think a NULL dereference is not unreasonable (better than adding needless
> extra cost checking).

Depends on if the remove is supposed to be a blocking remove, or if the
remove is supposed to be as the result of an event (which included the
queueing operation).

I believe common usage is the latter, so the current behaviour is correct.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.