All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hanna Czenczek <hreitz@redhat.com>
To: Eric Blake <eblake@redhat.com>, qemu-devel@nongnu.org
Cc: qemu-block@nongnu.org
Subject: Re: [PATCH v3 04/19] test-cutils: Test more integer corner cases
Date: Tue, 23 May 2023 19:25:28 +0200	[thread overview]
Message-ID: <5720a801-a6b7-1b9e-efdb-bceb7e55c6ce@redhat.com> (raw)
In-Reply-To: <20230522190441.64278-5-eblake@redhat.com>

On 22.05.23 21:04, Eric Blake wrote:
> We have quite a few undertested and underdocumented integer parsing
> corner cases.  To ensure that any changes we make in the code are
> intentional rather than accidental semantic changes, it is time to add
> more unit tests of existing behavior.
>
> In particular, this demonstrates that parse_uint() and qemu_strtou64()
> behave differently.  For "-0", it's hard to argue why parse_uint needs
> to reject it (it's not a negative integer), but the documentation sort
> of mentions it; but it is intentional that all other negative values
> are treated as ERANGE with value 0 (compared to qemu_strtou64()
> treating "-2" as success and UINT64_MAX-1, for example).
>
> Also, when mixing overflow/underflow with a check for no trailing
> junk, parse_uint_full favors ERANGE over EINVAL, while qemu_strto[iu]*
> favor EINVAL.  This behavior is outside the C standard, so we can pick
> whatever we want, but it would be nice to be consistent.
>
> Note that C requires that "9223372036854775808" fail strtoll() with
> ERANGE/INT64_MAX, but "-9223372036854775808" pass with INT64_MIN; we
> weren't testing this.  For strtol(), the behavior depends on whether
> long is 32- or 64-bits (the cutoff point either being the same as
> strtoll() or at "-2147483648").  Meanwhile, C is clear that
> "-18446744073709551615" pass stroull() (but not strtoll) with value 1,
> even though we want it to fail parse_uint().  And although
> qemu_strtoui() has no C counterpart, it makes more sense if we design
> it like 32-bit strtoul() (that is, where "-4294967296" be an alternate
> acceptable spelling for "1", but "-0xffffffff00000001" should be
> treated as overflow and return 0xffffffff rather than 1).  We aren't
> there yet, so some of the tests added in this patch have FIXME
> comments.
>
> However, note that C2x will (likely) be adding a SILENT semantic
> change, where C17 strtol("0b1", &ep, 2) returns 0 with ep="b1", but
> C2x will have it return 1 with ep="".  I did not feel like adding
> testing for those corner cases, in part because the next version of C
> is not standard and libc support for binary parsing is not yet
> wide-spread (as of this patch, glibc.git still misparses bare "0b":
> https://sourceware.org/bugzilla/show_bug.cgi?id=30371).
>
> Signed-off-by: Eric Blake <eblake@redhat.com>
> ---
>
> v3: use cmpuint in more places [Hanna], expose another strtoui flaw
> and add compaanion tests to strtoul, expand commit message, R-b dropped
> ---
>   tests/unit/test-cutils.c | 929 ++++++++++++++++++++++++++++++++++++---
>   1 file changed, 864 insertions(+), 65 deletions(-)

[...]

> @@ -1020,7 +1365,50 @@ static void test_qemu_strtol_max(void)
>
>   static void test_qemu_strtol_overflow(void)
>   {

[...]

> +    if (LONG_MAX == INT_MAX) {
> +        str = "0xffffffff00000001"; /* ULLONG_MAX - UNIT_MAX + 1 (not 1) */

s/UNIT/UINT/

> +        endptr = "somewhere";
> +        res = 999;
> +        err = qemu_strtol(str, &endptr, 0, &res);
> +        g_assert_cmpint(err, ==, -ERANGE);
> +        g_assert_cmpint(res, ==, LONG_MIN);
> +        g_assert_true(endptr == str + strlen(str));
> +    }

[...]

> @@ -1325,31 +1799,87 @@ static void test_qemu_strtoul_max(void)

[...]

>   static void test_qemu_strtoul_underflow(void)
>   {
> -    const char *str = "-99999999999999999999999999999999999999999999";
> -    char f = 'X';
> -    const char *endptr = &f;
> -    unsigned long res = 999;
> +    const char *str;
> +    const char *endptr;
> +    unsigned long res;
>       int err;
>
> +    /* 1 less than -ULONG_MAX */
> +    str = ULONG_MAX == UINT_MAX ? "-4294967296" : "-18446744073709551616";
> +    endptr = "somewhere";
> +    res = 999;
>       err = qemu_strtoul(str, &endptr, 0, &res);
> +    g_assert_cmpint(err, ==, -ERANGE);
> +    g_assert_cmpint(res, ==, ULONG_MAX);

Should be g_assert_cmpuint().

Reviewed-by: Hanna Czenczek <hreitz@redhat.com>



  reply	other threads:[~2023-05-23 17:26 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-22 19:04 [PATCH v3 00/19] Fix qemu_strtosz() read-out-of-bounds Eric Blake
2023-05-22 19:04 ` [PATCH v3 01/19] test-cutils: Avoid g_assert in unit tests Eric Blake
2023-05-22 19:04 ` [PATCH v3 02/19] test-cutils: Use g_assert_cmpuint where appropriate Eric Blake
2023-05-22 19:04 ` [PATCH v3 03/19] test-cutils: Test integral qemu_strto* value on failures Eric Blake
2023-05-22 19:04 ` [PATCH v3 04/19] test-cutils: Test more integer corner cases Eric Blake
2023-05-23 17:25   ` Hanna Czenczek [this message]
2023-05-23 19:19     ` Eric Blake
2023-05-22 19:04 ` [PATCH v3 05/19] cutils: Fix wraparound parsing in qemu_strtoui Eric Blake
2023-05-23 17:36   ` Hanna Czenczek
2023-05-22 19:04 ` [PATCH v3 06/19] cutils: Document differences between parse_uint and qemu_strtou64 Eric Blake
2023-05-22 19:04 ` [PATCH v3 07/19] cutils: Adjust signature of parse_uint[_full] Eric Blake
2023-05-22 19:04 ` [PATCH v3 08/19] cutils: Allow NULL endptr in parse_uint() Eric Blake
2023-05-22 19:04 ` [PATCH v3 09/19] test-cutils: Add coverage of qemu_strtod Eric Blake
2023-05-22 19:04 ` [PATCH v3 10/19] test-cutils: Prepare for upcoming semantic change in qemu_strtosz Eric Blake
2023-05-22 19:04 ` [PATCH v3 11/19] test-cutils: Refactor qemu_strtosz tests for less boilerplate Eric Blake
2023-05-22 19:04 ` [PATCH v3 12/19] cutils: Allow NULL str in qemu_strtosz Eric Blake
2023-05-22 19:04 ` [PATCH v3 13/19] numa: Check for qemu_strtosz_MiB error Eric Blake
2023-05-22 19:04 ` [PATCH v3 14/19] test-cutils: Add more coverage to qemu_strtosz Eric Blake
2023-05-22 19:04 ` [PATCH v3 15/19] cutils: Set value in all qemu_strtosz* error paths Eric Blake
2023-05-22 19:04 ` [PATCH v3 16/19] cutils: Set value in all integral qemu_strto* " Eric Blake
2023-05-22 19:04 ` [PATCH v3 17/19] cutils: Use parse_uint in qemu_strtosz for negative rejection Eric Blake
2023-05-22 19:04 ` [PATCH v3 18/19] cutils: Improve qemu_strtod* error paths Eric Blake
2023-05-22 19:04 ` [PATCH v3 19/19] cutils: Improve qemu_strtosz handling of fractions Eric Blake
2023-06-01 21:46   ` Eric Blake
2023-06-01 21:28 ` [PATCH v3 00/19] Fix qemu_strtosz() read-out-of-bounds Eric Blake

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5720a801-a6b7-1b9e-efdb-bceb7e55c6ce@redhat.com \
    --to=hreitz@redhat.com \
    --cc=eblake@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.