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>