From owner-freebsd-net@FreeBSD.ORG Tue Sep 12 16:42:34 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9ACD16A416; Tue, 12 Sep 2006 16:42:34 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61C2F43D45; Tue, 12 Sep 2006 16:42:34 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/8.12.11/smtpout13/MantshX 4.0) with ESMTP id k8CGgXfh028777; Tue, 12 Sep 2006 09:42:33 -0700 (PDT) Received: from [17.214.13.96] (a17-214-13-96.apple.com [17.214.13.96]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id k8CGgUA6005920; Tue, 12 Sep 2006 09:42:32 -0700 (PDT) In-Reply-To: <4506AE6D.1010300@freebsd.org> References: <450035AD.3040600@freebsd.org> <20060908010835.GA6334@heff.fud.org.nz> <45012EAA.4010303@freebsd.org> <20060912114312.GE8639@comp.chem.msu.su> <4506AE6D.1010300@freebsd.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2EDD6C39-62ED-4DE1-B5BF-368E8E701B2E@mac.com> Content-Transfer-Encoding: 7bit From: Chuck Swiger Date: Tue, 12 Sep 2006 09:42:30 -0700 To: Andre Oppermann X-Mailer: Apple Mail (2.752.2) X-Brightmail-Tracker: AAAAAQAAA+k= X-Language-Identified: TRUE Cc: freebsd-net@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Moving ethernet VLAN tags into the mbuf packet header (from mtags) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Sep 2006 16:42:34 -0000 On Sep 12, 2006, at 5:56 AM, Andre Oppermann wrote: >> Now I can't but do some nitpicking :-) In if_vlan.c, the "inenc" >> variable is set to 0 or 1 depending on the branch taken in the >> if-else clause. Then why to initialize it at its definition? I >> think that the better style would be: >> int inenc; >> if (m->m_flags & M_VLAN) { >> ... >> inenc = 0; >> } else { >> ... >> inenc = 1; >> } >> AFAIK, C compilers are clever enough to avoid false "uninitialized >> variable" warning for the code. > > Good point. This can certainly be improved. For the first patch > I tried to be as mechanical as I could be. So long as there does not exist another code path (via break, continue, goto, etc) which can avoid passing one statement or the other-- and so long as nobody later on adds code which changes the underlying assumption. In terms of efficiency, zero'ing a bunch of automatic variables which get put on the stack during function entry is usually cheaper to do than doing conditional initialization later on in the code. It depends on the underlying CPU architecture, but many have an instruction which can perform a bzero() or memset() rapidly. -- -Chuck