[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20110301152455.995eb661.akpm@linux-foundation.org>
Date: Tue, 1 Mar 2011 15:24:55 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Alexey Dobriyan <adobriyan@...il.com>
Cc: linux-kernel@...r.kernel.org, geert@...ux-m68k.org,
jj@...osbits.net, arnd@...db.de
Subject: Re: [PATCH] kstrto*: converting strings to integers done
(hopefully) right
On Sat, 26 Feb 2011 14:47:08 +0200
Alexey Dobriyan <adobriyan@...il.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?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists