@@ -2745,21 +2745,6 @@ static void test_qemu_strtosz_invalid(void)
g_assert_cmphex(res, ==, 0xbaadf00d);
g_assert_true(endptr == str);
- /* No floating point exponents */
- str = "1.5e1k";
- endptr = NULL;
- err = qemu_strtosz(str, &endptr, &res);
- g_assert_cmpint(err, ==, -EINVAL);
- g_assert_cmphex(res, ==, 0xbaadf00d);
- g_assert_true(endptr == str);
-
- str = "1.5E+0k";
- endptr = NULL;
- err = qemu_strtosz(str, &endptr, &res);
- g_assert_cmpint(err, ==, -EINVAL);
- g_assert_cmphex(res, ==, 0xbaadf00d);
- g_assert_true(endptr == str);
-
/* No hex fractions */
str = "0x1.8k";
endptr = NULL;
@@ -2863,6 +2848,33 @@ static void test_qemu_strtosz_trailing(void)
err = qemu_strtosz(str, NULL, &res);
g_assert_cmpint(err, ==, -EINVAL);
g_assert_cmphex(res, ==, 0xbaadf00d);
+
+ /* FIXME should stop parse after 'e'. No floating point exponents */
+ str = "1.5e1k";
+ endptr = NULL;
+ res = 0xbaadf00d;
+ err = qemu_strtosz(str, &endptr, &res);
+ g_assert_cmpint(err, ==, -EINVAL /* FIXME 0 */);
+ g_assert_cmphex(res, ==, 0xbaadf00d /* FIXME EiB * 1.5 */);
+ g_assert_true(endptr == str /* FIXME + 4 */);
+
+ res = 0xbaadf00d;
+ err = qemu_strtosz(str, NULL, &res);
+ g_assert_cmpint(err, ==, -EINVAL);
+ g_assert_cmpint(res, ==, 0xbaadf00d);
+
+ str = "1.5E+0k";
+ endptr = NULL;
+ res = 0xbaadf00d;
+ err = qemu_strtosz(str, &endptr, &res);
+ g_assert_cmpint(err, ==, -EINVAL /* FIXME 0 */);
+ g_assert_cmphex(res, ==, 0xbaadf00d /* FIXME EiB * 1.5 */);
+ g_assert_true(endptr == str /* FIXME + 4 */);
+
+ res = 0xbaadf00d;
+ err = qemu_strtosz(str, NULL, &res);
+ g_assert_cmpint(err, ==, -EINVAL);
+ g_assert_cmphex(res, ==, 0xbaadf00d);
}
static void test_qemu_strtosz_erange(void)
A quick search for 'qemu_strtosz' in the code base shows that outside of the testsuite, the ONLY place that passes a non-NULL pointer to @endptr of any variant of a size parser is in hmp.c (the 'o' parser of monitor_parse_arguments), and that particular caller warns of "extraneous characters at the end of line" unless the trailing bytes are purely whitespace. Thus, it makes no semantic difference at the high level whether we parse "1.5e1k" as "1" + ".5e1" + "k" (an attempt to use scientific notation in strtod with a scaling suffix of 'k' with no trailing junk, but which qemu_strtosz says should fail with EINVAL), or as "1.5e" + "1k" (a valid size with scaling suffix of 'e' for exabytes, followed by two junk bytes) - either way, any user passing such a string will get an error message about a parse failure. However, an upcoming patch to qemu_strtosz will fix other corner case bugs in handling the fractional portion of a size, and in doing so, it is easier to declare that qemu_strtosz() itself stops parsing at the first 'e' rather than blindly consuming whatever strtod() will recognize. Once that is fixed, the difference will be visible at the low level (getting a valid parse with trailing garbage when @endptr is non-NULL, while continuing to get -EINVAL when @endptr is NULL); this is easier to demonstrate by moving the affected strings from test_qemu_strtosz_invalid() (which declares them as always -EINVAL) to test_qemu_strtosz_trailing() (where @endptr affects behavior, for now with FIXME comments). Note that a similar argument could be made for having "0x1.5" or "0x1M" parse as 0x1 with ".5" or "M" as trailing junk, instead of blindly treating it as -EINVAL; however, as these cases do not suffer from the same problems as floating point, they are not worth changing at this time. Signed-off-by: Eric Blake <eblake@redhat.com> --- tests/unit/test-cutils.c | 42 ++++++++++++++++++++++++++-------------- 1 file changed, 27 insertions(+), 15 deletions(-)