Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Sep 2006 09:42:30 -0700
From:      Chuck Swiger <cswiger@mac.com>
To:        Andre Oppermann <andre@freebsd.org>
Cc:        freebsd-net@freebsd.org, freebsd-arch@freebsd.org
Subject:   Re: Moving ethernet VLAN tags into the mbuf packet header (from	mtags)
Message-ID:  <2EDD6C39-62ED-4DE1-B5BF-368E8E701B2E@mac.com>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2EDD6C39-62ED-4DE1-B5BF-368E8E701B2E>