From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932870AbcCGXJs (ORCPT <rfc822;w@1wt.eu>);
	Mon, 7 Mar 2016 18:09:48 -0500
Received: from mx1.redhat.com ([209.132.183.28]:47501 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S932346AbcCGXJf (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Mon, 7 Mar 2016 18:09:35 -0500
Date: Mon, 7 Mar 2016 18:09:32 -0500
From: Jessica Yu <jeyu@redhat.com>
To: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Cc: Andrew Morton <akpm@linux-foundation.org>,
        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: <20160307230932.GB12689@packer-debian-8-amd64.digitalocean.com>
References: <1456518059-7472-1-git-send-email-jeyu@redhat.com>
 <87r3fs4ezi.fsf@rasmusvillemoes.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <87r3fs4ezi.fsf@rasmusvillemoes.dk>
X-OS: Linux eisen.io 3.16.0-4-amd64 x86_64
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

+++ Rasmus Villemoes [03/03/16 00:49 +0100]:
>On Fri, Feb 26 2016, Jessica Yu <jeyu@redhat.com> wrote:
>
>> @@ -2714,6 +2718,57 @@ int vsscanf(const char *buf, const char *fmt, va_list args)
>>  			num++;
>>  		}
>>  		continue;
>> +		/*
>> +		 * Warning: This implementation of the '[' conversion specifier
>> +		 * deviates from its glibc counterpart in the following ways:
>> +		 * (1) It does NOT support ranges i.e. '-' is NOT a special character
>> +		 * (2) It cannot match the closing bracket ']' itself
>> +		 * (3) A field width is required
>> +		 * (4) '%*[' (discard matching input) is currently not supported
>> +		 *
>> +		 * Example usage:
>> +		 * ret = sscanf("00:0a:95","%2[^:]:%2[^:]:%2[^:]", buf1, buf2, buf3);
>> +		 * if (ret < 3)
>> +		 *    // etc..
>> +		 */
>> +		case '[':
>> +		{
>> +			char *s = (char *)va_arg(args, char *);
>> +			DECLARE_BITMAP(set, 256) = {0};
>> +			unsigned int len = 0;
>> +			bool negate = (*fmt == '^');
>> +
>> +			/* field width is required */
>> +			if (field_width == -1)
>> +				return num;
>> +
>> +			if (negate)
>> +				++fmt;
>> +
>> +			for ( ; *fmt && *fmt != ']'; ++fmt, ++len)
>> +				set_bit((u8)*fmt, set);
>> +
>> +			/* no ']' or no character set found */
>> +			if (!*fmt || !len)
>> +				return num;
>> +			++fmt;
>> +
>
>I think it might be useful to be able to do [^] to match any sequence of
>characters. If the user passed [] the code below won't match anything,
>so we'll return num anyway. In other words, I'd just omit the test for
>empty character set. Other than that, LGTM.

Thanks for the review. My only concern would be that that behavior
(i.e., have [^] match any sequence of characters) would also deviate
from glibc sccanf behavior (which matches nothing), and would need to
be documented as well. Perhaps we should best keep these differences
to a minimum, so as to prevent unexpected surprises.

Jessica