From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 2 16:51:08 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B7AF106564A for ; Thu, 2 Jun 2011 16:51:08 +0000 (UTC) (envelope-from la5lbtyi@aon.at) Received: from email.aon.at (nat-warsl417-02.aon.at [195.3.96.120]) by mx1.freebsd.org (Postfix) with ESMTP id D533D8FC0A for ; Thu, 2 Jun 2011 16:51:07 +0000 (UTC) Received: (qmail 10524 invoked from network); 2 Jun 2011 16:24:25 -0000 Received: from unknown (HELO email.aon.at) ([172.18.1.199]) (envelope-sender ) by fallback43.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 2 Jun 2011 16:24:25 -0000 Received: (qmail 8542 invoked from network); 2 Jun 2011 16:24:22 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on WARSBL605.highway.telekom.at X-Spam-Level: Received: from 188-23-43-10.adsl.highway.telekom.at (HELO gandalf.xyzzy) ([188.23.43.10]) (envelope-sender ) by smarthub90.highway.telekom.at (qmail-ldap-1.03) with SMTP for ; 2 Jun 2011 16:24:22 -0000 Received: from atpcdvvc.xyzzy (atpcdvvc.xyzzy [IPv6:fec0:0:0:4d42::84]) by gandalf.xyzzy (8.14.4/8.14.4) with ESMTP id p52GOLTA022972 for ; Thu, 2 Jun 2011 18:24:22 +0200 (CEST) (envelope-from la5lbtyi@aon.at) Message-ID: <4DE7B935.9040004@aon.at> Date: Thu, 02 Jun 2011 18:24:21 +0200 From: Martin Birgmeier User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110522 Thunderbird/3.1.10 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: some strange constructs (bugs?) in if_tun.c X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2011 16:51:08 -0000 I am looking at net/if_tun.c, function tunwrite() (this is 7.4, but 8.2 is nearly the same): There is a local variable "error" which is initialized to zero and then seemingly never changed, until it is used as a return value if m_uiotombuf() fails: ... int error = 0; ... if ((m = m_uiotombuf(uio, M_DONTWAIT, 0, 0, M_PKTHDR)) == NULL) { ifp->if_ierrors++; return (error); } ... a little further down, we see ... if (m->m_len < sizeof(family) && (m = m_pullup(m, sizeof(family))) == NULL) return (ENOBUFS); ... As far as I can see, the first return amounts to "drop the packet, but don't tell anything about it", whereas the second amounts to "drop the packet and say it's due to ENOBUFS". However, the first case is much more like ENOBUFS, so shouldn't we simply say "return (ENOBUFS)" there and remove the "error" variable altogether? There seem to be other functions in if_tun.c with a similar strange usage of an "error" variable. Regards, Martin