Re: [PATCH 06/10] parse_integer: convert mm/

From: Alexey Dobriyan
Date: Mon May 04 2015 - 11:09:26 EST


On Mon, May 4, 2015 at 5:33 PM, Rasmus Villemoes
<linux@xxxxxxxxxxxxxxxxxx> wrote:
> On Sat, May 02 2015, Alexey Dobriyan <adobriyan@xxxxxxxxx> wrote:
>
>> Convert mm/ directory away from deprecated simple_strto*() interface.
>>
>> One thing to note about parse_integer() and seemingly useless casts --
>> range of accepted values depends on result type.
>>
>> int val;
>> parse_integer(s, 0, &val);
>>
>> will accept negative integers, while
>>
>> int val;
>> parse_integer(s, 0, (unsigned int *)&val);
>>
>> will accept only 0 and positive integers.
>
> ... and then silently write a negative value to val if the parsed
> integer happens to be larger than INT_MAX.
>
> Again, I think passing cast expressions to parse_integer should be
> verboten.

> In these particular cases:
>
> * memtest_pattern should just be unsigned int - it's only ever used as
> such anyway, and it represents a count.
>
> * hashdist should be a boolean, but even in its current form, there's no
> reason to not just use parse_integer as-is. If people like to set it
> by passing -42 just let them.

In this particular code, maybe. The real use case is this:

int val = -1; //default
parse_integer(s, 0, (unsigned int *)&val); //accept unsigned only

Either you add cast here, or cast where you check that value is really
unsigned after parsing:

int val = -1;
parse_integer(s, 0, (unsiged int *)&val);
if (val < 0)
return -EINVAL;

Overall number of casts is preserved.

Just grep for simple_strto* and see how much error checking people do.
The aim of the patchset is to convert code, error checking is separate story.
I fixed types and added error checks in obvious cases but really:

static int memtest_pattern __initdata;
static int __init parse_memtest(char *arg)
{
if (arg)
memtest_pattern = simple_strtoul(arg, NULL, 0);

"int" and strtoul() => developer doesn't care, neither do I.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/