Date: Mon, 7 Mar 2016 20:07:53 -0500
From: Jessica Yu <jeyu@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        Kees Cook <keescook@chromium.org>, linux-kernel@vger.kernel.org
Subject: Re: sscanf: implement basic character sets
Message-ID: <20160308010753.GD12689@packer-debian-8-amd64.digitalocean.com>
References: <1456518059-7472-1-git-send-email-jeyu@redhat.com>
 <20160226202810.GA6566@packer-debian-8-amd64.digitalocean.com>
 <20160307231220.GC12689@packer-debian-8-amd64.digitalocean.com>
 <20160307152427.89422fd4d6c0696cb1b12911@linux-foundation.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <20160307152427.89422fd4d6c0696cb1b12911@linux-foundation.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3030
Lines: 63

+++ Andrew Morton [07/03/16 15:24 -0800]:
>On Mon, 7 Mar 2016 18:12:20 -0500 Jessica Yu <jeyu@redhat.com> wrote:
>
>> +++ Jessica Yu [26/02/16 15:28 -0500]:
>> >+++ Jessica Yu [26/02/16 15:20 -0500]:
>> >>Implement basic character sets for the '%[' conversion specifier.
>> >>
>> >>The '%[' conversion specifier matches a nonempty sequence of characters
>> >>from the specified set of accepted (or with '^', rejected) characters
>> >>between the brackets. The substring matched is to be made up of characters
>> >>in (or not in) the set. This is useful for matching substrings that are
>> >>delimited by something other than spaces.
>> >>
>> >>This implementation differs from its glibc counterpart in the following ways:
>> >>(1) No support for character ranges (e.g., 'a-z' or '0-9')
>> >>(2) The hyphen '-' is not a special character
>> >>(3) The closing bracket ']' cannot be matched
>> >>(4) No support (yet) for discarding matching input ('%*[')
>> >>
>> >>Signed-off-by: Jessica Yu <jeyu@redhat.com>
>> >
>> >Since this version is largely based on Rasmus' sample bitmap code
>> >(with only very minor tweaks), what is the best way to provide
>> >attribution in this case? A Suggested-by: tag or another
>> >Signed-off-by: tag (since actual code is involved)?
>>
>> Andrew, friendly ping on this patch and question? :-)
>
>Rasmus's Signed-off-by: would be most appropriate, please.
>
>I've queued the patch for some testing, however the changelog which
>used to have IMO-inadequate justification now has no justification at
>all!
>
>So please send along a paragraph or two which we can put in there to
>explain to people why we believe this change should be made to the
>kernel.  Thanks.

Andrew, I've included a more detailed explanation of the motivation
behind the patch below. Could you please append it to the end of the
original changelog? Thanks!
---

The motivation for adding character set support to sscanf originally
stemmed from the kernel livepatching project. An ongoing patchset
utilizes new livepatch Elf symbol and section names to store important
metadata livepatch needs to properly apply its patches. Such metadata
is stored in these section and symbol names as substrings delimited by
periods '.' and commas ','. For example, a livepatch symbol name might
look like this:

.klp.sym.vmlinux.printk,0

However, sscanf currently can only extract "substrings" delimited by
whitespace using the "%s" specifier. Thus for the above symbol name,
one cannot not use sscanf() to extract substrings "vmlinux" or "printk",
for example. A number of discussions on the livepatch mailing list
dealing with string parsing code for extracting these '.' and ','
delimited substrings eventually led to the conclusion that such code would
be completely unnecessary if the kernel sscanf() supported character sets.
Thus only a single sscanf() call would be necessary to extract these
substrings. In addition, such an addition to sscanf() could benefit other
areas of the kernel that might have a similar need in the future.