From owner-svn-src-all@FreeBSD.ORG Fri Dec 3 18:18:48 2010 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E177B10656C0; Fri, 3 Dec 2010 18:18:48 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.freebsd.org (Postfix) with ESMTP id 5DD408FC0A; Fri, 3 Dec 2010 18:18:47 +0000 (UTC) Received: from c211-30-187-94.carlnfd1.nsw.optusnet.com.au (c211-30-187-94.carlnfd1.nsw.optusnet.com.au [211.30.187.94]) by mail07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id oB3IIfg0029788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Dec 2010 05:18:42 +1100 Date: Sat, 4 Dec 2010 05:18:41 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Cran In-Reply-To: <20101203101651.7461ced0@core.draftnet> Message-ID: <20101204050508.Q4074@besplex.bde.org> References: <201012022219.oB2MJUx5031472@svn.freebsd.org> <20101203201705.O2228@besplex.bde.org> <20101203101651.7461ced0@core.draftnet> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Bruce Evans , Bruce Cran Subject: Re: svn commit: r216134 - in head: share/man/man9 sys/amd64/include sys/arm/include sys/i386/include sys/ia64/include sys/mips/include sys/pc98/include sys/powerpc/include sys/sparc64/include sys/sun4v... X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Dec 2010 18:18:49 -0000 On Fri, 3 Dec 2010, Bruce Cran wrote: > On Fri, 3 Dec 2010 20:45:12 +1100 (EST) > Bruce Evans wrote: > >> KASSERT() in little inline functions gives a lot of bloat for such an >> unlikely error. Stupid callers can still pass any garbage count >> except 0. > > Yes, this catches a specific case that hps raised a few years ago: > sending zero-length packets/frames would fail by causing the system to > hang. Should we just document the restriction in the man page and not > try and prevent it at runtime? That is enough for me, and hps should be the last person to write this bug :-). If zero lengths can be generated at runtime then they should be checked for in callers and not handled by panicing. Bruce