[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <49bbbcac-f970-bbb9-c66b-c9c25229cc6a@users.sourceforge.net>
Date: Fri, 28 Apr 2017 12:48:15 +0200
From: SF Markus Elfring <elfring@...rs.sourceforge.net>
To: Alexandre Belloni <alexandre.belloni@...e-electrons.com>
Cc: alsa-devel@...a-project.org, Jaroslav Kysela <perex@...ex.cz>,
Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>,
Nikita Yushchenko <nikita.yoush@...entembedded.com>,
Takashi Iwai <tiwai@...e.com>, kernel-janitors@...r.kernel.org,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [alsa-devel] [PATCH 1/3] ASoC: simple-card: Use devm_kcalloc() in
asoc_simple_card_parse_aux_devs()
>> @@ -334,8 +334,8 @@ static int asoc_simple_card_parse_aux_devs(struct device_node *node,
>> if (n <= 0)
>> return -EINVAL;
>>
>> - card->aux_dev = devm_kzalloc(dev,
>> - n * sizeof(*card->aux_dev), GFP_KERNEL);
>> + card->aux_dev = devm_kcalloc(dev, n, sizeof(*card->aux_dev),
>> + GFP_KERNEL);
>
> Do you realize that this change has absolutely no value
We can have different software development opinions about such a source code adjustment.
Does it improve the indentation for the parameters which are passed to this function call?
> and just makes the code slower (one more test in the allocation path)?
Do we stumble on a target conflict for the shown implementation detail?
Does the previous size calculation contain the general possibility for
an integer overflow?
https://cwe.mitre.org/data/definitions/190.html
The value for the variable “len” (and also “n”) might be small enough so that
the computed value will usually not exceed the data type limit in this use case.
Regards,
Markus
Powered by blists - more mailing lists