Date: Sat, 4 Dec 2010 05:18:41 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Bruce Cran <bruce@cran.org.uk> Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Bruce Evans <brde@optusnet.com.au>, Bruce Cran <brucec@FreeBSD.org> 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... Message-ID: <20101204050508.Q4074@besplex.bde.org> In-Reply-To: <20101203101651.7461ced0@core.draftnet> References: <201012022219.oB2MJUx5031472@svn.freebsd.org> <20101203201705.O2228@besplex.bde.org> <20101203101651.7461ced0@core.draftnet>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 3 Dec 2010, Bruce Cran wrote: > On Fri, 3 Dec 2010 20:45:12 +1100 (EST) > Bruce Evans <brde@optusnet.com.au> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101204050508.Q4074>