From owner-freebsd-current  Wed Jan  8 15:57:38 1997
Return-Path: <owner-current>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id PAA10347
          for current-outgoing; Wed, 8 Jan 1997 15:57:38 -0800 (PST)
Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id PAA10334;
          Wed, 8 Jan 1997 15:57:34 -0800 (PST)
Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.3/CET-v2.1) with SMTP id XAA17064; Wed, 8 Jan 1997 23:57:31 GMT
Date: Thu, 9 Jan 1997 08:57:31 +0900 (JST)
From: Michael Hancock <michaelh@cet.co.jp>
To: phk@freebsd.org
cc: current@freebsd.org
Subject: Re: <sys/queue.h> potential for panic
In-Reply-To: <12720.852123157@critter.dk.tfs.com>
Message-ID: <Pine.SV4.3.95.970109083859.16689B-100000@parkplace.cet.co.jp>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

On Wed, 1 Jan 1997, Poul-Henning Kamp wrote:

> 
> 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 ?

Extra safety checks in the kernel runtime would be unacceptable for
performance freaks, like me.

A diagnostic would define responsibility at the expense of a little
compile time.

There are three points of view here:

1) Robustness	(poul)
2) Correctness & production binary performance (me)
3) Compile-time performance & less source code (enough people in core)

Regards, Mike Hancock