Re: [PATCH] kstrto*: converting strings to integers done (hopefully) right

[Andrew Morton <akpm@linux-foundation.org>]

On Sat, 26 Feb 2011 14:47:08 +0200
Alexey Dobriyan <adobriyan@gmail.com> wrote:

> 1. simple_strto*() do not contain overflow checks and crufty,
>    libc way to indicate failure.
> 2. strict_strto*() also do not have overflow checks but the name and
>    comments pretend they do.
> 3. Both families have only "long long" and "long" variants,
>    but users want strtou8()
> 4. Both "simple" and "strict" prefixes are wrong:
>    Simple doesn't exactly say what's so simple, strict should not exist
>    because conversion should be strict by default.
> 
> The solution is to use "k" prefix and add convertors for more types.
> Enter
> 	kstrtoull()
> 	kstrtoll()
> 	kstrtoul()
> 	kstrtol()
> 	kstrtouint()
> 	kstrtoint()
> 
> 	kstrtou64()
> 	kstrtos64()
> 	kstrtou32()
> 	kstrtos32()
> 	kstrtou16()
> 	kstrtos16()
> 	kstrtou8()
> 	kstrtos8()
> 
> Include runtime testsuite (somewhat incomplete) as well.
> 
> strict_strto*() become deprecated, stubbed to kstrto*() and
> eventually will be removed altogether.

Note that they're deprecated but not marked __deprecated.  That's OK.

> Use kstrto*() in code today!

If you can stomach perl, please prepare a checkpatch patch which alerts
people to the new regime.

> Note: on some archs _kstrtoul() and _kstrtol() are left in tree, even if
>       they'll be unused at runtime. This is temporarily solution,
>       because I don't want to hardcode list of archs where these
>       functions aren't needed. Current solution with sizeof() and
>       __alignof__ at least always works.
> ---
> 
>  Let's merge this into mainline, so I can send individual patches
>  to subsystem maintainers. Whole tree is already converted locally.

Talk to us about the tighter checking.  There's a risk here that
current userspace which "works" will cease to work if we add additional
input checking.  Even if that userspace was broken and
just-happened-to-work, adding additional checks might cause disruption?