linux-kernel - Re: [PATCH] sscanf: don't ignore field widths for numeric conversions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <5097902C02000078000A64BF@nat28.tlf.novell.com>
Date:	Mon, 05 Nov 2012 09:08:44 +0000
From:	"Jan Beulich" <JBeulich@...e.com>
To:	"Andrew Morton" <akpm@...ux-foundation.org>
Cc:	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] sscanf: don't ignore field widths for numeric
 conversions

>>> On 02.11.12 at 22:32, Andrew Morton <akpm@...ux-foundation.org> wrote:
> On Fri, 02 Nov 2012 14:44:08 +0000
> "Jan Beulich" <JBeulich@...e.com> wrote:
> 
>> This is another step towards better standard conformance. Rather than
>> adding a local buffer to store the specified portion of the string
>> (with the need to enforce an arbitrary maximum supported width to
>> limit the buffer size), do a maximum width conversion and then drop as
>> much of it as is necessary to meet the caller's request.
>> 
>> Also fail on negative field widths.
>> 
>> ...
>>
>> +				simple_strtol(str, &next, base) :
> 
> simple_strtol() kerndoc says "This function is obsolete.  Please use
> kstrtol instead."  Can we?

No, we can't - kstrtoXX() fail on non-zero terminated strings. If
anything we'd have to switch to using the parsing functions
underlying _kstrtoXX() (effectively open-coding simple_strtoXX()),
but other than a simply replacement as you suggest (and as I had
intended originally) I wouldn't want to put _that_ change into this
same patch.

I think the simple_strtoXX() functions are sitting inside lib/vsprintf.c
for a good reason, and the obsoletion aspect of them should
merely involve their status of not only not being static, but even
being exported. Their use as helper functions ought to be fine
within that file.

Jan

--
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/