From: "Arend van Spriel" <arend@broadcom.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Brett Rudley <brudley@broadcom.com>,
Roland Vossen <rvossen@broadcom.com>,
"Franky (Zhenhui) Lin" <frankyl@broadcom.com>,
Kan Yan <kanyan@broadcom.com>,
"John W. Linville" <linville@tuxdriver.com>,
Hante Meuleman <meuleman@broadcom.com>,
Pieter-Paul Giesberts <pieterpg@broadcom.com>,
linux-wireless@vger.kernel.org, brcm80211-dev-list@broadcom.com,
kernel-janitors@vger.kernel.org
Subject: Re: [patch 2/3] brcmfmac: fix end of loop check (signedness bug)
Date: Thu, 04 Oct 2012 16:24:11 +0000 [thread overview]
Message-ID: <506DB82B.9010106@broadcom.com> (raw)
In-Reply-To: <20121003060631.GB3802@elgon.mountain>
On 10/03/2012 08:06 AM, Dan Carpenter wrote:
> The problem here is that we loop until "remained_buf_len" is less than
> zero, but since it is unsigned, it never is.
>
> "remained_buf_len" has to be large enough to hold the value from
> "mgmt_ie_buf_len". That variable is type u32, but it only holds small
> values so I have changed to both variables to int.
>
> Also I removed the bogus initialization from "mgmt_ie_buf_len" so that
> GCC can detect if it is used unitialized. I moved the declaration of
> "remained_buf_len" closer to where it is used so it's easier to read.
>
Hi Dan,
Good catch. I applied the patch internally on our HEAD and had it
reviewed. We did not take moving the declaration as we prefer to have
all variables at the top of the function. It makes it easier to find
what is declared in a function and whether exceeding the local variable
limit mentioned in Chapter 6. Functions of the CodingStyle (we are
exceeding it already ;-) ).
Are you ok with us submitting it? It would be sent out for 3.8 or do you
prefer to have it fixed in 3.7?
Gr. AvS
WARNING: multiple messages have this Message-ID (diff)
From: "Arend van Spriel" <arend@broadcom.com>
To: "Dan Carpenter" <dan.carpenter@oracle.com>
Cc: "Brett Rudley" <brudley@broadcom.com>,
"Roland Vossen" <rvossen@broadcom.com>,
"Franky (Zhenhui) Lin" <frankyl@broadcom.com>,
"Kan Yan" <kanyan@broadcom.com>,
"John W. Linville" <linville@tuxdriver.com>,
"Hante Meuleman" <meuleman@broadcom.com>,
"Pieter-Paul Giesberts" <pieterpg@broadcom.com>,
linux-wireless@vger.kernel.org, brcm80211-dev-list@broadcom.com,
kernel-janitors@vger.kernel.org
Subject: Re: [patch 2/3] brcmfmac: fix end of loop check (signedness bug)
Date: Thu, 4 Oct 2012 18:24:11 +0200 [thread overview]
Message-ID: <506DB82B.9010106@broadcom.com> (raw)
In-Reply-To: <20121003060631.GB3802@elgon.mountain>
On 10/03/2012 08:06 AM, Dan Carpenter wrote:
> The problem here is that we loop until "remained_buf_len" is less than
> zero, but since it is unsigned, it never is.
>
> "remained_buf_len" has to be large enough to hold the value from
> "mgmt_ie_buf_len". That variable is type u32, but it only holds small
> values so I have changed to both variables to int.
>
> Also I removed the bogus initialization from "mgmt_ie_buf_len" so that
> GCC can detect if it is used unitialized. I moved the declaration of
> "remained_buf_len" closer to where it is used so it's easier to read.
>
Hi Dan,
Good catch. I applied the patch internally on our HEAD and had it
reviewed. We did not take moving the declaration as we prefer to have
all variables at the top of the function. It makes it easier to find
what is declared in a function and whether exceeding the local variable
limit mentioned in Chapter 6. Functions of the CodingStyle (we are
exceeding it already ;-) ).
Are you ok with us submitting it? It would be sent out for 3.8 or do you
prefer to have it fixed in 3.7?
Gr. AvS
next prev parent reply other threads:[~2012-10-04 16:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-03 6:06 [patch 2/3] brcmfmac: fix end of loop check (signedness bug) Dan Carpenter
2012-10-03 6:06 ` Dan Carpenter
2012-10-04 16:24 ` Arend van Spriel [this message]
2012-10-04 16:24 ` Arend van Spriel
2012-10-04 18:42 ` Dan Carpenter
2012-10-04 18:42 ` Dan Carpenter
2012-10-04 21:10 ` Arend van Spriel
2012-10-04 21:10 ` Arend van Spriel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=506DB82B.9010106@broadcom.com \
--to=arend@broadcom.com \
--cc=brcm80211-dev-list@broadcom.com \
--cc=brudley@broadcom.com \
--cc=dan.carpenter@oracle.com \
--cc=frankyl@broadcom.com \
--cc=kanyan@broadcom.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=meuleman@broadcom.com \
--cc=pieterpg@broadcom.com \
--cc=rvossen@broadcom.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.