From: Nenghua Cao <[email protected]>
sound/soc/soc-core.c:2708:6-13: WARNING: Assignment of
bool to 0/1
sound/soc/soc-core.c:2726:3-10: WARNING: Assignment of
bool to 0/1
sound/soc/soc-core.c:2264:1-7: Replace memcpy with
struct assignment
More information about semantic patching is available at
http://coccinelle.lip6.fr/
Signed-off-by: Nenghua Cao <[email protected]>
---
sound/soc/soc-core.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index fb598cb..c59b3ea 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -2413,7 +2413,7 @@ struct snd_kcontrol *snd_soc_cnew(const struct snd_kcontrol_new *_template,
struct snd_kcontrol *kcontrol;
char *name = NULL;
- memcpy(&template, _template, sizeof(template));
+ memcpy(&template, _template, sizeof(struct snd_kcontrol_new));
template.index = 0;
if (!long_name)
@@ -2818,7 +2818,7 @@ int snd_soc_put_volsw(struct snd_kcontrol *kcontrol,
unsigned int mask = (1 << fls(max)) - 1;
unsigned int invert = mc->invert;
int err;
- bool type_2r = 0;
+ bool type_2r = false;
unsigned int val2 = 0;
unsigned int val, val_mask;
@@ -2836,7 +2836,7 @@ int snd_soc_put_volsw(struct snd_kcontrol *kcontrol,
val |= val2 << rshift;
} else {
val2 = val2 << shift;
- type_2r = 1;
+ type_2r = true;
}
}
err = snd_soc_update_bits_locked(codec, reg, val_mask, val);
--
1.7.0.4
On Fri, Feb 21, 2014 at 04:06:10PM +0800, Nenghua Cao wrote:
> --- a/sound/soc/soc-core.c
> +++ b/sound/soc/soc-core.c
> @@ -2413,7 +2413,7 @@ struct snd_kcontrol *snd_soc_cnew(const struct snd_kcontrol_new *_template,
> struct snd_kcontrol *kcontrol;
> char *name = NULL;
>
> - memcpy(&template, _template, sizeof(template));
> + memcpy(&template, _template, sizeof(struct snd_kcontrol_new));
> template.index = 0;
>
> if (!long_name)
This looks like a regression - it's better form to use the object name
rather than the type of the object since this prevents errors if the
type changes. What coccinelle was suggesting here was to replace with a
simple assingment statement rather than change the argument within the
memcpy(), I think this stops the warning showing because of that issue
since it makes it harder for coccinelle to figure out that this is a
memcpy() of the whole object.
On 02/22/2014 10:52 AM, Mark Brown wrote:
> On Fri, Feb 21, 2014 at 04:06:10PM +0800, Nenghua Cao wrote:
>
>> --- a/sound/soc/soc-core.c
>> +++ b/sound/soc/soc-core.c
>> @@ -2413,7 +2413,7 @@ struct snd_kcontrol *snd_soc_cnew(const struct snd_kcontrol_new *_template,
>> struct snd_kcontrol *kcontrol;
>> char *name = NULL;
>>
>> - memcpy(&template, _template, sizeof(template));
>> + memcpy(&template, _template, sizeof(struct snd_kcontrol_new));
>> template.index = 0;
>>
>> if (!long_name)
>
> This looks like a regression - it's better form to use the object name
> rather than the type of the object since this prevents errors if the
> type changes. What coccinelle was suggesting here was to replace with a
> simple assingment statement rather than change the argument within the
> memcpy(), I think this stops the warning showing because of that issue
> since it makes it harder for coccinelle to figure out that this is a
> memcpy() of the whole object.
>
Hi, Mark
I am not familiar with coccinelle. But it isn't reasonable and
convenient to use simple assignment instead of memcpy() here. So let's
retain it. I will submit another patch to fix "Assignment of bool to
0/1" issue. How do you think about it?
On Mon, Feb 24, 2014 at 11:05:14AM +0800, Nenghua Cao wrote:
> On 02/22/2014 10:52 AM, Mark Brown wrote:
> > type changes. What coccinelle was suggesting here was to replace with a
> > simple assingment statement rather than change the argument within the
> > memcpy(), I think this stops the warning showing because of that issue
> I am not familiar with coccinelle. But it isn't reasonable and
> convenient to use simple assignment instead of memcpy() here. So let's
> retain it. I will submit another patch to fix "Assignment of bool to
> 0/1" issue. How do you think about it?
Well, the two should be separate patches anyway but it's totally
reasonable to do an assigment - what it's telling you is that with
modern C "a = b" is valid even if a and b are structs.