From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:54939)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1TvuBW-0000H3-HG
	for qemu-devel@nongnu.org; Thu, 17 Jan 2013 13:27:33 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1TvuBT-00077e-F3
	for qemu-devel@nongnu.org; Thu, 17 Jan 2013 13:27:30 -0500
Received: from mx1.redhat.com ([209.132.183.28]:6704)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lersek@redhat.com>) id 1TvuBT-00076x-7M
	for qemu-devel@nongnu.org; Thu, 17 Jan 2013 13:27:27 -0500
Message-ID: <50F842FD.9060204@redhat.com>
Date: Thu, 17 Jan 2013 19:29:17 +0100
From: Laszlo Ersek <lersek@redhat.com>
MIME-Version: 1.0
References: <1358360933-5323-1-git-send-email-ehabkost@redhat.com>
	<1358360933-5323-2-git-send-email-ehabkost@redhat.com>
In-Reply-To: <1358360933-5323-2-git-send-email-ehabkost@redhat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 1/8] cutils: unsigned int parsing functions
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Chegu Vinod <chegu_vinod@hp.com>, qemu-devel@nongnu.org, Anthony Liguori <anthony@codemonkey.ws>

On 01/16/13 19:28, Eduardo Habkost wrote:

> +static void test_parse_uint_negative(void)
> +{
> +    unsigned long long i = 999;
> +    char f = 'X';
> +    char *endptr = &f;
> +    const char *str = " \t -321";
> +    int r;
> +
> +    r = parse_uint(str, &i, &endptr, 0);
> +
> +    g_assert_cmpint(r, ==, -ERANGE);
> +    g_assert_cmpint(i, ==, 0);
> +    g_assert(endptr == str + 3);
> +}

I think it would be more true to the strtol() family if in this case

(a) we reported -EINVAL (invalid subject sequence) -- but I certainly
don't insist on that,

(b) and, independently,

(b1) we either consumed all of the whitespace sequence *and* the subject
sequence (which would be consistent with ERANGE; see
test_parse_uint_overflow()),

(b2) or we didn't consume anything (not even part of the whitespace
sequence). This would be easy to implement and also consistent with the
strtol() family's behavior when it sees an invalid subject sequence:

"If the subject sequence is empty or does not have the expected form, no
conversion is performed; the value of /str/ is stored in the object
pointed to by /endptr/, provided that /endptr/ is not a null pointer."

But I don't insist on (b) either :)

Reviewed-by: Laszlo Ersek <lersek@redhat.com>