Date: Mon, 6 Jan 1997 18:15:51 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: dg@root.com Cc: phk@freebsd.org, current@freebsd.org Subject: Re: <sys/queue.h> potential for panic Message-ID: <199701070115.SAA13256@phaeton.artisoft.com> In-Reply-To: <199701011422.GAA10526@root.com> from "David Greenman" at Jan 1, 97 06:22:49 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701070115.SAA13256>