From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
To: Takashi Iwai <tiwai@suse.de>
Cc: Clemens Ladisch <clemens@ladisch.de>,
alsa-devel@alsa-project.org, kernel-janitors@vger.kernel.org,
Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [patch 1/2] ALSA: oxfw: some signedness bugs
Date: Mon, 15 Dec 2014 02:01:18 +0900 [thread overview]
Message-ID: <548DC25E.5030504@sakamocchi.jp> (raw)
In-Reply-To: <s5hy4qb5ufo.wl-tiwai@suse.de>
On Dec 14 2014 02:30, Takashi Iwai wrote:
> At Sat, 13 Dec 2014 19:14:46 +0900,
> Takashi Sakamoto wrote:
>>
>> On Dec 13 2014 16:04, Dan Carpenter wrote:
>>> On Sat, Dec 13, 2014 at 02:06:59PM +0900, Takashi Sakamoto wrote:
>>>> On Dec 13 2014 04:27, Dan Carpenter wrote:
>>>>> This code tends to use unsigned variables by default and it causes
>>>>> signedness bugs when we use negative variables for error handling.
>>>>> The "i" and "j" variables are used to iterated over small positive
>>>>> values and so they should be type "int". The "len" variable doesn't
>>>>> *need* to be signed but it should be signed to make the code easier to
>>>>> read and audit.
>>>>>
>>>>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> Note that Dan's suggestions are about the variables like "i" and "j".
> These are used normally for small loop counts, and they are int in a
> standard idiom. If they are declared as another type, you force
> reader's attention *unnecessarily*, and it decreases the readability
> (i.e. they have to read the loop code as somewhat special even if
> it's a normal loop). This is the only big drawback, and the rest
> merit/demerit are almost ignorable, IMO.
>
> Of course, in some cases, a loop count might be better in unsigned.
> But then a different variable name should be used instead.
>
> After all, this is rather a minor issue, almost a bikeshed topic, so I
> didn't care much while reviewing your patches, and I still don't care
> whether this fix patch will have int or unsigned for i. But, it'd be
> good if you keep this information in your mind, at least.
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Thanks
Takashi Sakamoto
o-takashi@sakamocchi.jp
WARNING: multiple messages have this Message-ID (diff)
From: Takashi Sakamoto <o-takashi@sakamocchi.jp>
To: Takashi Iwai <tiwai@suse.de>
Cc: Clemens Ladisch <clemens@ladisch.de>,
alsa-devel@alsa-project.org, kernel-janitors@vger.kernel.org,
Dan Carpenter <dan.carpenter@oracle.com>
Subject: Re: [patch 1/2] ALSA: oxfw: some signedness bugs
Date: Sun, 14 Dec 2014 17:01:18 +0000 [thread overview]
Message-ID: <548DC25E.5030504@sakamocchi.jp> (raw)
In-Reply-To: <s5hy4qb5ufo.wl-tiwai@suse.de>
On Dec 14 2014 02:30, Takashi Iwai wrote:
> At Sat, 13 Dec 2014 19:14:46 +0900,
> Takashi Sakamoto wrote:
>>
>> On Dec 13 2014 16:04, Dan Carpenter wrote:
>>> On Sat, Dec 13, 2014 at 02:06:59PM +0900, Takashi Sakamoto wrote:
>>>> On Dec 13 2014 04:27, Dan Carpenter wrote:
>>>>> This code tends to use unsigned variables by default and it causes
>>>>> signedness bugs when we use negative variables for error handling.
>>>>> The "i" and "j" variables are used to iterated over small positive
>>>>> values and so they should be type "int". The "len" variable doesn't
>>>>> *need* to be signed but it should be signed to make the code easier to
>>>>> read and audit.
>>>>>
>>>>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> Note that Dan's suggestions are about the variables like "i" and "j".
> These are used normally for small loop counts, and they are int in a
> standard idiom. If they are declared as another type, you force
> reader's attention *unnecessarily*, and it decreases the readability
> (i.e. they have to read the loop code as somewhat special even if
> it's a normal loop). This is the only big drawback, and the rest
> merit/demerit are almost ignorable, IMO.
>
> Of course, in some cases, a loop count might be better in unsigned.
> But then a different variable name should be used instead.
>
> After all, this is rather a minor issue, almost a bikeshed topic, so I
> didn't care much while reviewing your patches, and I still don't care
> whether this fix patch will have int or unsigned for i. But, it'd be
> good if you keep this information in your mind, at least.
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Thanks
Takashi Sakamoto
o-takashi@sakamocchi.jp
next prev parent reply other threads:[~2014-12-14 17:01 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-12 19:27 [patch 1/2] ALSA: oxfw: some signedness bugs Dan Carpenter
2014-12-12 19:27 ` Dan Carpenter
2014-12-13 5:06 ` Takashi Sakamoto
2014-12-13 5:06 ` Takashi Sakamoto
2014-12-13 7:04 ` Dan Carpenter
2014-12-13 7:04 ` Dan Carpenter
2014-12-13 10:14 ` Takashi Sakamoto
2014-12-13 10:14 ` Takashi Sakamoto
2014-12-13 11:35 ` Dan Carpenter
2014-12-13 11:35 ` Dan Carpenter
2014-12-13 11:38 ` Dan Carpenter
2014-12-13 11:38 ` Dan Carpenter
2014-12-13 17:30 ` Takashi Iwai
2014-12-13 17:30 ` Takashi Iwai
2014-12-14 17:01 ` Takashi Sakamoto [this message]
2014-12-14 17:01 ` Takashi Sakamoto
2014-12-15 9:03 ` Takashi Iwai
2014-12-15 9:03 ` Takashi Iwai
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=548DC25E.5030504@sakamocchi.jp \
--to=o-takashi@sakamocchi.jp \
--cc=alsa-devel@alsa-project.org \
--cc=clemens@ladisch.de \
--cc=dan.carpenter@oracle.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=tiwai@suse.de \
/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.