2012-11-30 15:21:02 +00:00
|
|
|
/*
|
2016-01-04 20:45:51 +00:00
|
|
|
* Copyright (C) 2012-2016 Red Hat, Inc.
|
2012-11-30 15:21:02 +00:00
|
|
|
*
|
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2.1 of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
* License along with this library. If not, see
|
|
|
|
* <http://www.gnu.org/licenses/>.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <config.h>
|
|
|
|
|
|
|
|
|
|
|
|
#include "testutils.h"
|
2012-12-12 17:59:27 +00:00
|
|
|
#include "virlog.h"
|
2012-11-30 15:21:02 +00:00
|
|
|
#include "virstring.h"
|
|
|
|
|
|
|
|
#define VIR_FROM_THIS VIR_FROM_NONE
|
|
|
|
|
2014-02-28 12:16:17 +00:00
|
|
|
VIR_LOG_INIT("tests.stringtest");
|
|
|
|
|
2016-12-09 10:52:28 +00:00
|
|
|
struct testStreqData {
|
|
|
|
const char *a;
|
|
|
|
const char *b;
|
|
|
|
};
|
|
|
|
|
|
|
|
static int testStreq(const void *args)
|
|
|
|
{
|
|
|
|
const struct testStreqData *data = args;
|
|
|
|
bool equal = true;
|
|
|
|
bool streq_rv, strneq_rv;
|
|
|
|
size_t i;
|
|
|
|
|
|
|
|
if ((size_t) data->a ^ (size_t) data->b)
|
|
|
|
equal = false;
|
|
|
|
if (data->a && data->b) {
|
|
|
|
for (i = 0; data->a[i] != '\0'; i++) {
|
|
|
|
if (data->b[i] == '\0' ||
|
|
|
|
data->a[i] != data->b[i]) {
|
|
|
|
equal = false;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
streq_rv = STREQ_NULLABLE(data->a, data->b);
|
|
|
|
strneq_rv = STRNEQ_NULLABLE(data->a, data->b);
|
|
|
|
|
|
|
|
if (streq_rv != equal) {
|
2020-01-27 12:52:23 +00:00
|
|
|
fprintf(stderr,
|
|
|
|
"STREQ not working correctly. Expected %d got %d",
|
|
|
|
(int) equal, (int) streq_rv);
|
2019-11-12 20:46:29 +00:00
|
|
|
return -1;
|
2016-12-09 10:52:28 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (strneq_rv == equal) {
|
2020-01-27 12:52:23 +00:00
|
|
|
fprintf(stderr,
|
|
|
|
"STRNEQ not working correctly. Expected %d got %d",
|
|
|
|
(int) equal, (int) strneq_rv);
|
2019-11-12 20:46:29 +00:00
|
|
|
return -1;
|
2016-12-09 10:52:28 +00:00
|
|
|
}
|
|
|
|
|
2019-11-12 20:46:29 +00:00
|
|
|
return 0;
|
2016-12-09 10:52:28 +00:00
|
|
|
}
|
|
|
|
|
2012-11-30 15:21:02 +00:00
|
|
|
|
2013-11-28 11:14:59 +00:00
|
|
|
static int
|
2019-10-14 12:45:03 +00:00
|
|
|
testStringSortCompare(const void *opaque G_GNUC_UNUSED)
|
2013-11-28 11:14:59 +00:00
|
|
|
{
|
|
|
|
const char *randlist[] = {
|
|
|
|
"tasty", "astro", "goat", "chicken", "turducken",
|
|
|
|
};
|
|
|
|
const char *randrlist[] = {
|
|
|
|
"tasty", "astro", "goat", "chicken", "turducken",
|
|
|
|
};
|
|
|
|
const char *sortlist[] = {
|
|
|
|
"astro", "chicken", "goat", "tasty", "turducken",
|
|
|
|
};
|
|
|
|
const char *sortrlist[] = {
|
|
|
|
"turducken", "tasty", "goat", "chicken", "astro",
|
|
|
|
};
|
|
|
|
size_t i;
|
|
|
|
|
lib: Replace qsort() with g_qsort_with_data()
While glibc provides qsort(), which usually is just a mergesort,
until sorting arrays so huge that temporary array used by
mergesort would not fit into physical memory (which in our case
is never), we are not guaranteed it'll use mergesort. The
advantage of mergesort is clear - it's stable. IOW, if we have an
array of values parsed from XML, qsort() it and produce some
output based on those values, we can then compare the output with
some expected output, line by line.
But with newer glibc this is all history. After [1], qsort() is
no longer mergesort but introsort instead, which is not stable.
This is suboptimal, because in some cases we want to preserve
order of equal items. For instance, in ebiptablesApplyNewRules(),
nwfilter rules are sorted by their priority. But if two rules
have the same priority, we want to keep them in the order they
appear in the XML. Since it's hard/needless work to identify
places where stable or unstable sorting is needed, let's just
play it safe and use stable sorting everywhere.
Fortunately, glib provides g_qsort_with_data() which indeed
implement mergesort and it's a drop in replacement for qsort(),
almost. It accepts fifth argument (pointer to opaque data), that
is passed to comparator function, which then accepts three
arguments.
We have to keep one occurance of qsort() though - in NSS module
which deliberately does not link with glib.
1: https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=03bf8357e8291857a435afcc3048e0b697b6cc04
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2023-11-22 13:58:49 +00:00
|
|
|
g_qsort_with_data(randlist, G_N_ELEMENTS(randlist),
|
|
|
|
sizeof(randlist[0]), virStringSortCompare, NULL);
|
|
|
|
g_qsort_with_data(randrlist, G_N_ELEMENTS(randrlist),
|
|
|
|
sizeof(randrlist[0]), virStringSortRevCompare, NULL);
|
2013-11-28 11:14:59 +00:00
|
|
|
|
2019-10-15 11:55:26 +00:00
|
|
|
for (i = 0; i < G_N_ELEMENTS(randlist); i++) {
|
2013-11-28 11:14:59 +00:00
|
|
|
if (STRNEQ(randlist[i], sortlist[i])) {
|
|
|
|
fprintf(stderr, "sortlist[%zu] '%s' != randlist[%zu] '%s'\n",
|
|
|
|
i, sortlist[i], i, randlist[i]);
|
2019-11-12 20:46:29 +00:00
|
|
|
return -1;
|
2013-11-28 11:14:59 +00:00
|
|
|
}
|
|
|
|
if (STRNEQ(randrlist[i], sortrlist[i])) {
|
|
|
|
fprintf(stderr, "sortrlist[%zu] '%s' != randrlist[%zu] '%s'\n",
|
|
|
|
i, sortrlist[i], i, randrlist[i]);
|
2019-11-12 20:46:29 +00:00
|
|
|
return -1;
|
2013-11-28 11:14:59 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-11-12 20:46:29 +00:00
|
|
|
return 0;
|
2013-11-28 11:14:59 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2014-01-23 09:28:29 +00:00
|
|
|
struct stringSearchData {
|
|
|
|
const char *str;
|
|
|
|
const char *regexp;
|
|
|
|
size_t maxMatches;
|
|
|
|
size_t expectNMatches;
|
|
|
|
const char **expectMatches;
|
|
|
|
bool expectError;
|
|
|
|
};
|
|
|
|
|
|
|
|
static int
|
util: fix uint parsing on 64-bit platforms
Commit f22b7899 called to light a long-standing latent bug: the
behavior of virStrToLong_ui was different on 32-bit platforms
than on 64-bit platforms. Curse you, C type promotion and
narrowing rules, and strtoul specification. POSIX says that for
a 32-bit long, strtol handles only 2^32 values [LONG_MIN to
LONG_MAX] while strtoul handles 2^33 - 1 values [-ULONG_MAX to
ULONG_MAX] with twos-complement wraparound for negatives. Thus,
parsing -1 as unsigned long produces ULONG_MAX, rather than a
range error. We WANT[1] this same shortcut for turning -1 into
UINT_MAX when parsing to int; and get it for free with 32-bit
long. But with 64-bit long, ULONG_MAX is outside the range
of int and we were rejecting it as invalid; meanwhile, we were
silently treating -18446744073709551615 as 1 even though it
textually exceeds INT_MIN. Too bad there's not a strtoui() in
libc that does guaranteed parsing to int, regardless of the size
of long.
The bug has been latent since 2007, introduced by Jim Meyering
in commit 5d25419 in the attempt to eradicate unsafe use of
strto[u]l when parsing ints and longs. How embarrassing that we
are only discovering it now - so I'm adding a testsuite to ensure
that it covers all the corner cases we care about.
[1] Ideally, we really want the caller to be able to choose whether
to allow negative numbers to wrap around to their 2s-complement
counterpart, as in strtoul, or to force a stricter input range
of [0 to UINT_MAX] by rejecting negative signs; this will be added
in a later patch for all three int types.
This patch is tested on both 32- and 64-bit; the enhanced
virstringtest passes on both platforms, while virstoragetest now
reliably fails on both platforms instead of just 32-bit platforms.
That test will be fixed later.
* src/util/virstring.c (virStrToLong_ui): Ensure same behavior
regardless of platform long size.
* tests/virstringtest.c (testStringToLong): New function.
(mymain): Comprehensively test string to long parsing.
Signed-off-by: Eric Blake <eblake@redhat.com>
2014-04-30 20:46:18 +00:00
|
|
|
testStringSearch(const void *opaque)
|
2014-01-23 09:28:29 +00:00
|
|
|
{
|
|
|
|
const struct stringSearchData *data = opaque;
|
2021-11-01 09:34:10 +00:00
|
|
|
g_auto(GStrv) matches = NULL;
|
2014-01-23 09:28:29 +00:00
|
|
|
ssize_t nmatches;
|
|
|
|
|
|
|
|
nmatches = virStringSearch(data->str, data->regexp,
|
|
|
|
data->maxMatches, &matches);
|
|
|
|
|
|
|
|
if (data->expectError) {
|
|
|
|
if (nmatches != -1) {
|
|
|
|
fprintf(stderr, "expected error on %s but got %zd matches\n",
|
|
|
|
data->str, nmatches);
|
2021-12-10 15:21:59 +00:00
|
|
|
return -1;
|
2014-01-23 09:28:29 +00:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
size_t i;
|
|
|
|
|
|
|
|
if (nmatches < 0) {
|
|
|
|
fprintf(stderr, "expected %zu matches on %s but got error\n",
|
|
|
|
data->expectNMatches, data->str);
|
2021-12-10 15:21:59 +00:00
|
|
|
return -1;
|
2014-01-23 09:28:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (nmatches != data->expectNMatches) {
|
|
|
|
fprintf(stderr, "expected %zu matches on %s but got %zd\n",
|
|
|
|
data->expectNMatches, data->str, nmatches);
|
2021-12-10 15:21:59 +00:00
|
|
|
return -1;
|
2014-01-23 09:28:29 +00:00
|
|
|
}
|
|
|
|
|
2021-02-05 17:03:26 +00:00
|
|
|
if (g_strv_length(matches) != nmatches) {
|
|
|
|
fprintf(stderr, "expected %zu matches on %s but got %u matches\n",
|
2014-01-23 09:28:29 +00:00
|
|
|
data->expectNMatches, data->str,
|
2021-02-05 17:03:26 +00:00
|
|
|
g_strv_length(matches));
|
2021-12-10 15:21:59 +00:00
|
|
|
return -1;
|
2014-01-23 09:28:29 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < nmatches; i++) {
|
|
|
|
if (STRNEQ(matches[i], data->expectMatches[i])) {
|
|
|
|
fprintf(stderr, "match %zu expected '%s' but got '%s'\n",
|
|
|
|
i, data->expectMatches[i], matches[i]);
|
2021-12-10 15:21:59 +00:00
|
|
|
return -1;
|
2014-01-23 09:28:29 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-12-10 15:21:59 +00:00
|
|
|
return 0;
|
2014-01-23 09:28:29 +00:00
|
|
|
}
|
|
|
|
|
2014-02-19 20:30:46 +00:00
|
|
|
|
2017-05-11 15:16:13 +00:00
|
|
|
struct stringMatchData {
|
|
|
|
const char *str;
|
|
|
|
const char *regexp;
|
|
|
|
bool expectMatch;
|
|
|
|
};
|
|
|
|
|
|
|
|
static int
|
|
|
|
testStringMatch(const void *opaque)
|
|
|
|
{
|
|
|
|
const struct stringMatchData *data = opaque;
|
|
|
|
bool match;
|
|
|
|
|
|
|
|
match = virStringMatch(data->str, data->regexp);
|
|
|
|
|
|
|
|
if (data->expectMatch) {
|
|
|
|
if (!match) {
|
|
|
|
fprintf(stderr, "expected match for '%s' on '%s' but got no match\n",
|
|
|
|
data->regexp, data->str);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if (match) {
|
|
|
|
fprintf(stderr, "expected no match for '%s' on '%s' but got match\n",
|
|
|
|
data->regexp, data->str);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2014-02-19 20:30:46 +00:00
|
|
|
struct stringReplaceData {
|
|
|
|
const char *haystack;
|
|
|
|
const char *oldneedle;
|
|
|
|
const char *newneedle;
|
|
|
|
const char *result;
|
|
|
|
};
|
|
|
|
|
|
|
|
static int
|
2019-10-14 12:45:03 +00:00
|
|
|
testStringReplace(const void *opaque G_GNUC_UNUSED)
|
2014-02-19 20:30:46 +00:00
|
|
|
{
|
|
|
|
const struct stringReplaceData *data = opaque;
|
2021-09-04 20:37:31 +00:00
|
|
|
g_autofree char *result = NULL;
|
2014-02-19 20:30:46 +00:00
|
|
|
|
|
|
|
result = virStringReplace(data->haystack,
|
|
|
|
data->oldneedle,
|
|
|
|
data->newneedle);
|
|
|
|
|
|
|
|
if (STRNEQ_NULLABLE(data->result, result)) {
|
|
|
|
fprintf(stderr, "Expected '%s' but got '%s'\n",
|
|
|
|
data->result, NULLSTR(result));
|
2021-09-04 20:41:36 +00:00
|
|
|
return -1;
|
2014-02-19 20:30:46 +00:00
|
|
|
}
|
|
|
|
|
2021-09-04 20:41:36 +00:00
|
|
|
return 0;
|
2014-02-19 20:30:46 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
util: fix uint parsing on 64-bit platforms
Commit f22b7899 called to light a long-standing latent bug: the
behavior of virStrToLong_ui was different on 32-bit platforms
than on 64-bit platforms. Curse you, C type promotion and
narrowing rules, and strtoul specification. POSIX says that for
a 32-bit long, strtol handles only 2^32 values [LONG_MIN to
LONG_MAX] while strtoul handles 2^33 - 1 values [-ULONG_MAX to
ULONG_MAX] with twos-complement wraparound for negatives. Thus,
parsing -1 as unsigned long produces ULONG_MAX, rather than a
range error. We WANT[1] this same shortcut for turning -1 into
UINT_MAX when parsing to int; and get it for free with 32-bit
long. But with 64-bit long, ULONG_MAX is outside the range
of int and we were rejecting it as invalid; meanwhile, we were
silently treating -18446744073709551615 as 1 even though it
textually exceeds INT_MIN. Too bad there's not a strtoui() in
libc that does guaranteed parsing to int, regardless of the size
of long.
The bug has been latent since 2007, introduced by Jim Meyering
in commit 5d25419 in the attempt to eradicate unsafe use of
strto[u]l when parsing ints and longs. How embarrassing that we
are only discovering it now - so I'm adding a testsuite to ensure
that it covers all the corner cases we care about.
[1] Ideally, we really want the caller to be able to choose whether
to allow negative numbers to wrap around to their 2s-complement
counterpart, as in strtoul, or to force a stricter input range
of [0 to UINT_MAX] by rejecting negative signs; this will be added
in a later patch for all three int types.
This patch is tested on both 32- and 64-bit; the enhanced
virstringtest passes on both platforms, while virstoragetest now
reliably fails on both platforms instead of just 32-bit platforms.
That test will be fixed later.
* src/util/virstring.c (virStrToLong_ui): Ensure same behavior
regardless of platform long size.
* tests/virstringtest.c (testStringToLong): New function.
(mymain): Comprehensively test string to long parsing.
Signed-off-by: Eric Blake <eblake@redhat.com>
2014-04-30 20:46:18 +00:00
|
|
|
struct stringToLongData {
|
|
|
|
const char *str;
|
|
|
|
const char *suffix;
|
|
|
|
int si; /* syntax-check doesn't like bare 'i' */
|
|
|
|
int si_ret;
|
|
|
|
unsigned int ui;
|
|
|
|
int ui_ret;
|
|
|
|
/* No expected results for long: on 32-bit platforms, it is the
|
|
|
|
* same as int, on 64-bit platforms it is the same as long long */
|
|
|
|
long long ll;
|
|
|
|
int ll_ret;
|
|
|
|
unsigned long long ull;
|
|
|
|
int ull_ret;
|
|
|
|
};
|
|
|
|
|
|
|
|
/* This test makes assumptions about our compilation platform that are
|
|
|
|
* not guaranteed by POSIX. Good luck to you if you are crazy enough
|
2020-01-17 16:00:27 +00:00
|
|
|
* to try and port libvirt to a platform with 16-bit int. */
|
2020-01-09 10:39:55 +00:00
|
|
|
G_STATIC_ASSERT(sizeof(int) == 4);
|
|
|
|
G_STATIC_ASSERT(sizeof(long) == sizeof(int) || sizeof(long) == sizeof(long long));
|
|
|
|
G_STATIC_ASSERT(sizeof(long long) == 8);
|
util: fix uint parsing on 64-bit platforms
Commit f22b7899 called to light a long-standing latent bug: the
behavior of virStrToLong_ui was different on 32-bit platforms
than on 64-bit platforms. Curse you, C type promotion and
narrowing rules, and strtoul specification. POSIX says that for
a 32-bit long, strtol handles only 2^32 values [LONG_MIN to
LONG_MAX] while strtoul handles 2^33 - 1 values [-ULONG_MAX to
ULONG_MAX] with twos-complement wraparound for negatives. Thus,
parsing -1 as unsigned long produces ULONG_MAX, rather than a
range error. We WANT[1] this same shortcut for turning -1 into
UINT_MAX when parsing to int; and get it for free with 32-bit
long. But with 64-bit long, ULONG_MAX is outside the range
of int and we were rejecting it as invalid; meanwhile, we were
silently treating -18446744073709551615 as 1 even though it
textually exceeds INT_MIN. Too bad there's not a strtoui() in
libc that does guaranteed parsing to int, regardless of the size
of long.
The bug has been latent since 2007, introduced by Jim Meyering
in commit 5d25419 in the attempt to eradicate unsafe use of
strto[u]l when parsing ints and longs. How embarrassing that we
are only discovering it now - so I'm adding a testsuite to ensure
that it covers all the corner cases we care about.
[1] Ideally, we really want the caller to be able to choose whether
to allow negative numbers to wrap around to their 2s-complement
counterpart, as in strtoul, or to force a stricter input range
of [0 to UINT_MAX] by rejecting negative signs; this will be added
in a later patch for all three int types.
This patch is tested on both 32- and 64-bit; the enhanced
virstringtest passes on both platforms, while virstoragetest now
reliably fails on both platforms instead of just 32-bit platforms.
That test will be fixed later.
* src/util/virstring.c (virStrToLong_ui): Ensure same behavior
regardless of platform long size.
* tests/virstringtest.c (testStringToLong): New function.
(mymain): Comprehensively test string to long parsing.
Signed-off-by: Eric Blake <eblake@redhat.com>
2014-04-30 20:46:18 +00:00
|
|
|
|
|
|
|
static int
|
|
|
|
testStringToLong(const void *opaque)
|
|
|
|
{
|
|
|
|
const struct stringToLongData *data = opaque;
|
|
|
|
int ret = 0;
|
|
|
|
char *end;
|
|
|
|
unsigned long ul;
|
2014-05-01 02:11:09 +00:00
|
|
|
bool negative;
|
|
|
|
|
|
|
|
if (data->suffix)
|
|
|
|
negative = !!memchr(data->str, '-',
|
|
|
|
strlen(data->str) - strlen(data->suffix));
|
|
|
|
else
|
|
|
|
negative = !!strchr(data->str, '-');
|
util: fix uint parsing on 64-bit platforms
Commit f22b7899 called to light a long-standing latent bug: the
behavior of virStrToLong_ui was different on 32-bit platforms
than on 64-bit platforms. Curse you, C type promotion and
narrowing rules, and strtoul specification. POSIX says that for
a 32-bit long, strtol handles only 2^32 values [LONG_MIN to
LONG_MAX] while strtoul handles 2^33 - 1 values [-ULONG_MAX to
ULONG_MAX] with twos-complement wraparound for negatives. Thus,
parsing -1 as unsigned long produces ULONG_MAX, rather than a
range error. We WANT[1] this same shortcut for turning -1 into
UINT_MAX when parsing to int; and get it for free with 32-bit
long. But with 64-bit long, ULONG_MAX is outside the range
of int and we were rejecting it as invalid; meanwhile, we were
silently treating -18446744073709551615 as 1 even though it
textually exceeds INT_MIN. Too bad there's not a strtoui() in
libc that does guaranteed parsing to int, regardless of the size
of long.
The bug has been latent since 2007, introduced by Jim Meyering
in commit 5d25419 in the attempt to eradicate unsafe use of
strto[u]l when parsing ints and longs. How embarrassing that we
are only discovering it now - so I'm adding a testsuite to ensure
that it covers all the corner cases we care about.
[1] Ideally, we really want the caller to be able to choose whether
to allow negative numbers to wrap around to their 2s-complement
counterpart, as in strtoul, or to force a stricter input range
of [0 to UINT_MAX] by rejecting negative signs; this will be added
in a later patch for all three int types.
This patch is tested on both 32- and 64-bit; the enhanced
virstringtest passes on both platforms, while virstoragetest now
reliably fails on both platforms instead of just 32-bit platforms.
That test will be fixed later.
* src/util/virstring.c (virStrToLong_ui): Ensure same behavior
regardless of platform long size.
* tests/virstringtest.c (testStringToLong): New function.
(mymain): Comprehensively test string to long parsing.
Signed-off-by: Eric Blake <eblake@redhat.com>
2014-04-30 20:46:18 +00:00
|
|
|
|
2017-11-03 12:09:47 +00:00
|
|
|
#define TEST_ONE(Str, Suff, Type, Fn, Fmt, Exp, Exp_ret) \
|
|
|
|
do { \
|
|
|
|
Type value = 5; \
|
|
|
|
int result; \
|
|
|
|
end = (char *) "oops"; \
|
|
|
|
result = virStrToLong_ ## Fn(Str, Suff ? &end : NULL, \
|
|
|
|
0, &value); \
|
|
|
|
/* On failure, end is modified, value is unchanged */ \
|
|
|
|
if (result != (Exp_ret)) { \
|
|
|
|
fprintf(stderr, \
|
|
|
|
"type " #Fn " returned %d expected %d\n", \
|
|
|
|
result, Exp_ret); \
|
|
|
|
ret = -1; \
|
|
|
|
} \
|
|
|
|
if (value != ((Exp_ret) ? 5 : Exp)) { \
|
|
|
|
fprintf(stderr, \
|
|
|
|
"type " #Fn " value " Fmt " expected " Fmt "\n", \
|
|
|
|
value, ((Exp_ret) ? 5 : Exp)); \
|
|
|
|
ret = -1; \
|
|
|
|
} \
|
|
|
|
if (Suff && STRNEQ_NULLABLE(Suff, end)) { \
|
|
|
|
fprintf(stderr, \
|
|
|
|
"type " #Fn " end '%s' expected '%s'\n", \
|
|
|
|
NULLSTR(end), Suff); \
|
|
|
|
ret = -1; \
|
|
|
|
} \
|
util: fix uint parsing on 64-bit platforms
Commit f22b7899 called to light a long-standing latent bug: the
behavior of virStrToLong_ui was different on 32-bit platforms
than on 64-bit platforms. Curse you, C type promotion and
narrowing rules, and strtoul specification. POSIX says that for
a 32-bit long, strtol handles only 2^32 values [LONG_MIN to
LONG_MAX] while strtoul handles 2^33 - 1 values [-ULONG_MAX to
ULONG_MAX] with twos-complement wraparound for negatives. Thus,
parsing -1 as unsigned long produces ULONG_MAX, rather than a
range error. We WANT[1] this same shortcut for turning -1 into
UINT_MAX when parsing to int; and get it for free with 32-bit
long. But with 64-bit long, ULONG_MAX is outside the range
of int and we were rejecting it as invalid; meanwhile, we were
silently treating -18446744073709551615 as 1 even though it
textually exceeds INT_MIN. Too bad there's not a strtoui() in
libc that does guaranteed parsing to int, regardless of the size
of long.
The bug has been latent since 2007, introduced by Jim Meyering
in commit 5d25419 in the attempt to eradicate unsafe use of
strto[u]l when parsing ints and longs. How embarrassing that we
are only discovering it now - so I'm adding a testsuite to ensure
that it covers all the corner cases we care about.
[1] Ideally, we really want the caller to be able to choose whether
to allow negative numbers to wrap around to their 2s-complement
counterpart, as in strtoul, or to force a stricter input range
of [0 to UINT_MAX] by rejecting negative signs; this will be added
in a later patch for all three int types.
This patch is tested on both 32- and 64-bit; the enhanced
virstringtest passes on both platforms, while virstoragetest now
reliably fails on both platforms instead of just 32-bit platforms.
That test will be fixed later.
* src/util/virstring.c (virStrToLong_ui): Ensure same behavior
regardless of platform long size.
* tests/virstringtest.c (testStringToLong): New function.
(mymain): Comprehensively test string to long parsing.
Signed-off-by: Eric Blake <eblake@redhat.com>
2014-04-30 20:46:18 +00:00
|
|
|
} while (0)
|
|
|
|
|
|
|
|
TEST_ONE(data->str, data->suffix, int, i, "%d",
|
|
|
|
data->si, data->si_ret);
|
|
|
|
TEST_ONE(data->str, data->suffix, unsigned int, ui, "%u",
|
|
|
|
data->ui, data->ui_ret);
|
2014-05-01 02:11:09 +00:00
|
|
|
if (negative)
|
|
|
|
TEST_ONE(data->str, data->suffix, unsigned int, uip, "%u", 0U, -1);
|
|
|
|
else
|
|
|
|
TEST_ONE(data->str, data->suffix, unsigned int, uip, "%u",
|
|
|
|
data->ui, data->ui_ret);
|
util: fix uint parsing on 64-bit platforms
Commit f22b7899 called to light a long-standing latent bug: the
behavior of virStrToLong_ui was different on 32-bit platforms
than on 64-bit platforms. Curse you, C type promotion and
narrowing rules, and strtoul specification. POSIX says that for
a 32-bit long, strtol handles only 2^32 values [LONG_MIN to
LONG_MAX] while strtoul handles 2^33 - 1 values [-ULONG_MAX to
ULONG_MAX] with twos-complement wraparound for negatives. Thus,
parsing -1 as unsigned long produces ULONG_MAX, rather than a
range error. We WANT[1] this same shortcut for turning -1 into
UINT_MAX when parsing to int; and get it for free with 32-bit
long. But with 64-bit long, ULONG_MAX is outside the range
of int and we were rejecting it as invalid; meanwhile, we were
silently treating -18446744073709551615 as 1 even though it
textually exceeds INT_MIN. Too bad there's not a strtoui() in
libc that does guaranteed parsing to int, regardless of the size
of long.
The bug has been latent since 2007, introduced by Jim Meyering
in commit 5d25419 in the attempt to eradicate unsafe use of
strto[u]l when parsing ints and longs. How embarrassing that we
are only discovering it now - so I'm adding a testsuite to ensure
that it covers all the corner cases we care about.
[1] Ideally, we really want the caller to be able to choose whether
to allow negative numbers to wrap around to their 2s-complement
counterpart, as in strtoul, or to force a stricter input range
of [0 to UINT_MAX] by rejecting negative signs; this will be added
in a later patch for all three int types.
This patch is tested on both 32- and 64-bit; the enhanced
virstringtest passes on both platforms, while virstoragetest now
reliably fails on both platforms instead of just 32-bit platforms.
That test will be fixed later.
* src/util/virstring.c (virStrToLong_ui): Ensure same behavior
regardless of platform long size.
* tests/virstringtest.c (testStringToLong): New function.
(mymain): Comprehensively test string to long parsing.
Signed-off-by: Eric Blake <eblake@redhat.com>
2014-04-30 20:46:18 +00:00
|
|
|
|
|
|
|
/* We hate adding new API with 'long', and prefer 'int' or 'long
|
|
|
|
* long' instead, since platform-specific results are evil */
|
|
|
|
ul = (sizeof(int) == sizeof(long)) ? data->ui : data->ull;
|
|
|
|
TEST_ONE(data->str, data->suffix, unsigned long, ul, "%lu",
|
|
|
|
ul, (sizeof(int) == sizeof(long)) ? data->ui_ret : data->ull_ret);
|
2014-05-01 02:11:09 +00:00
|
|
|
if (negative)
|
|
|
|
TEST_ONE(data->str, data->suffix, unsigned long, ulp, "%lu", 0UL, -1);
|
|
|
|
else
|
|
|
|
TEST_ONE(data->str, data->suffix, unsigned long, ulp, "%lu", ul,
|
|
|
|
(sizeof(int) == sizeof(long)) ? data->ui_ret : data->ull_ret);
|
util: fix uint parsing on 64-bit platforms
Commit f22b7899 called to light a long-standing latent bug: the
behavior of virStrToLong_ui was different on 32-bit platforms
than on 64-bit platforms. Curse you, C type promotion and
narrowing rules, and strtoul specification. POSIX says that for
a 32-bit long, strtol handles only 2^32 values [LONG_MIN to
LONG_MAX] while strtoul handles 2^33 - 1 values [-ULONG_MAX to
ULONG_MAX] with twos-complement wraparound for negatives. Thus,
parsing -1 as unsigned long produces ULONG_MAX, rather than a
range error. We WANT[1] this same shortcut for turning -1 into
UINT_MAX when parsing to int; and get it for free with 32-bit
long. But with 64-bit long, ULONG_MAX is outside the range
of int and we were rejecting it as invalid; meanwhile, we were
silently treating -18446744073709551615 as 1 even though it
textually exceeds INT_MIN. Too bad there's not a strtoui() in
libc that does guaranteed parsing to int, regardless of the size
of long.
The bug has been latent since 2007, introduced by Jim Meyering
in commit 5d25419 in the attempt to eradicate unsafe use of
strto[u]l when parsing ints and longs. How embarrassing that we
are only discovering it now - so I'm adding a testsuite to ensure
that it covers all the corner cases we care about.
[1] Ideally, we really want the caller to be able to choose whether
to allow negative numbers to wrap around to their 2s-complement
counterpart, as in strtoul, or to force a stricter input range
of [0 to UINT_MAX] by rejecting negative signs; this will be added
in a later patch for all three int types.
This patch is tested on both 32- and 64-bit; the enhanced
virstringtest passes on both platforms, while virstoragetest now
reliably fails on both platforms instead of just 32-bit platforms.
That test will be fixed later.
* src/util/virstring.c (virStrToLong_ui): Ensure same behavior
regardless of platform long size.
* tests/virstringtest.c (testStringToLong): New function.
(mymain): Comprehensively test string to long parsing.
Signed-off-by: Eric Blake <eblake@redhat.com>
2014-04-30 20:46:18 +00:00
|
|
|
|
|
|
|
TEST_ONE(data->str, data->suffix, long long, ll, "%lld",
|
|
|
|
data->ll, data->ll_ret);
|
|
|
|
TEST_ONE(data->str, data->suffix, unsigned long long, ull, "%llu",
|
|
|
|
data->ull, data->ull_ret);
|
2014-05-01 02:11:09 +00:00
|
|
|
if (negative)
|
|
|
|
TEST_ONE(data->str, data->suffix, unsigned long long, ullp, "%llu",
|
|
|
|
0ULL, -1);
|
|
|
|
else
|
|
|
|
TEST_ONE(data->str, data->suffix, unsigned long long, ullp, "%llu",
|
|
|
|
data->ull, data->ull_ret);
|
util: fix uint parsing on 64-bit platforms
Commit f22b7899 called to light a long-standing latent bug: the
behavior of virStrToLong_ui was different on 32-bit platforms
than on 64-bit platforms. Curse you, C type promotion and
narrowing rules, and strtoul specification. POSIX says that for
a 32-bit long, strtol handles only 2^32 values [LONG_MIN to
LONG_MAX] while strtoul handles 2^33 - 1 values [-ULONG_MAX to
ULONG_MAX] with twos-complement wraparound for negatives. Thus,
parsing -1 as unsigned long produces ULONG_MAX, rather than a
range error. We WANT[1] this same shortcut for turning -1 into
UINT_MAX when parsing to int; and get it for free with 32-bit
long. But with 64-bit long, ULONG_MAX is outside the range
of int and we were rejecting it as invalid; meanwhile, we were
silently treating -18446744073709551615 as 1 even though it
textually exceeds INT_MIN. Too bad there's not a strtoui() in
libc that does guaranteed parsing to int, regardless of the size
of long.
The bug has been latent since 2007, introduced by Jim Meyering
in commit 5d25419 in the attempt to eradicate unsafe use of
strto[u]l when parsing ints and longs. How embarrassing that we
are only discovering it now - so I'm adding a testsuite to ensure
that it covers all the corner cases we care about.
[1] Ideally, we really want the caller to be able to choose whether
to allow negative numbers to wrap around to their 2s-complement
counterpart, as in strtoul, or to force a stricter input range
of [0 to UINT_MAX] by rejecting negative signs; this will be added
in a later patch for all three int types.
This patch is tested on both 32- and 64-bit; the enhanced
virstringtest passes on both platforms, while virstoragetest now
reliably fails on both platforms instead of just 32-bit platforms.
That test will be fixed later.
* src/util/virstring.c (virStrToLong_ui): Ensure same behavior
regardless of platform long size.
* tests/virstringtest.c (testStringToLong): New function.
(mymain): Comprehensively test string to long parsing.
Signed-off-by: Eric Blake <eblake@redhat.com>
2014-04-30 20:46:18 +00:00
|
|
|
|
|
|
|
#undef TEST_ONE
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2017-07-09 23:05:55 +00:00
|
|
|
struct stringToDoubleData {
|
|
|
|
const char *str;
|
|
|
|
const char *end_ptr;
|
|
|
|
double res;
|
|
|
|
};
|
|
|
|
|
|
|
|
/* This test checks if double strings are successfully converted to double
|
|
|
|
* number considering the byproduct string too. */
|
|
|
|
static int
|
|
|
|
testStringToDouble(const void *opaque)
|
|
|
|
{
|
|
|
|
const struct stringToDoubleData *data = opaque;
|
|
|
|
int ret = -1;
|
|
|
|
char *end_ptr = NULL;
|
|
|
|
double res = 0;
|
|
|
|
|
|
|
|
/* end_ptr returns or a substring or an empty string.
|
|
|
|
* It never returns a NULL pointer. */
|
|
|
|
if ((ret = virStrToDouble(data->str,
|
|
|
|
data->end_ptr ? &end_ptr : NULL,
|
|
|
|
&res)) < 0) {
|
|
|
|
fprintf(stderr, "Convert error of '%s', expected '%lf'\n",
|
|
|
|
data->str, data->res);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (res != data->res) {
|
|
|
|
fprintf(stderr, "Returned '%lf', expected '%lf'\n",
|
|
|
|
res, data->res);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Comparing substrings. */
|
|
|
|
if (STRNEQ_NULLABLE(end_ptr, data->end_ptr)) {
|
|
|
|
fprintf(stderr, "Expected substring '%s', but got '%s'\n",
|
|
|
|
end_ptr, data->end_ptr);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2014-05-19 12:20:09 +00:00
|
|
|
|
2015-04-14 10:06:44 +00:00
|
|
|
struct testStripData {
|
2014-10-07 15:27:40 +00:00
|
|
|
const char *string;
|
|
|
|
const char *result;
|
|
|
|
};
|
|
|
|
|
|
|
|
static int testStripIPv6Brackets(const void *args)
|
|
|
|
{
|
2015-04-14 10:06:44 +00:00
|
|
|
const struct testStripData *data = args;
|
2021-09-04 20:37:31 +00:00
|
|
|
g_autofree char *res = NULL;
|
2014-10-07 15:27:40 +00:00
|
|
|
|
2019-10-20 11:49:46 +00:00
|
|
|
res = g_strdup(data->string);
|
2014-10-07 15:27:40 +00:00
|
|
|
|
|
|
|
virStringStripIPv6Brackets(res);
|
|
|
|
|
|
|
|
if (STRNEQ_NULLABLE(res, data->result)) {
|
|
|
|
fprintf(stderr, "Returned '%s', expected '%s'\n",
|
|
|
|
NULLSTR(res), NULLSTR(data->result));
|
2021-09-04 20:41:36 +00:00
|
|
|
return -1;
|
2014-10-07 15:27:40 +00:00
|
|
|
}
|
|
|
|
|
2021-09-04 20:41:36 +00:00
|
|
|
return 0;
|
2014-10-07 15:27:40 +00:00
|
|
|
}
|
|
|
|
|
2015-04-14 10:30:16 +00:00
|
|
|
static int testStripControlChars(const void *args)
|
|
|
|
{
|
|
|
|
const struct testStripData *data = args;
|
2021-09-04 20:37:31 +00:00
|
|
|
g_autofree char *res = NULL;
|
2015-04-14 10:30:16 +00:00
|
|
|
|
2019-10-20 11:49:46 +00:00
|
|
|
res = g_strdup(data->string);
|
2015-04-14 10:30:16 +00:00
|
|
|
|
|
|
|
virStringStripControlChars(res);
|
|
|
|
|
|
|
|
if (STRNEQ_NULLABLE(res, data->result)) {
|
|
|
|
fprintf(stderr, "Returned '%s', expected '%s'\n",
|
|
|
|
NULLSTR(res), NULLSTR(data->result));
|
2021-09-04 20:41:36 +00:00
|
|
|
return -1;
|
2015-04-14 10:30:16 +00:00
|
|
|
}
|
|
|
|
|
2021-09-04 20:41:36 +00:00
|
|
|
return 0;
|
2015-04-14 10:30:16 +00:00
|
|
|
}
|
2014-10-07 15:27:40 +00:00
|
|
|
|
2017-12-18 14:46:53 +00:00
|
|
|
struct testFilterData {
|
|
|
|
const char *string;
|
|
|
|
const char *valid;
|
|
|
|
const char *result;
|
|
|
|
};
|
|
|
|
|
|
|
|
static int testFilterChars(const void *args)
|
|
|
|
{
|
|
|
|
const struct testFilterData *data = args;
|
2021-09-04 20:37:31 +00:00
|
|
|
g_autofree char *res = NULL;
|
2017-12-18 14:46:53 +00:00
|
|
|
|
2019-10-20 11:49:46 +00:00
|
|
|
res = g_strdup(data->string);
|
2017-12-18 14:46:53 +00:00
|
|
|
|
|
|
|
virStringFilterChars(res, data->valid);
|
|
|
|
|
|
|
|
if (STRNEQ_NULLABLE(res, data->result)) {
|
|
|
|
fprintf(stderr, "Returned '%s', expected '%s'\n",
|
|
|
|
NULLSTR(res), NULLSTR(data->result));
|
2021-09-04 20:41:36 +00:00
|
|
|
return -1;
|
2017-12-18 14:46:53 +00:00
|
|
|
}
|
|
|
|
|
2021-09-04 20:41:36 +00:00
|
|
|
return 0;
|
2017-12-18 14:46:53 +00:00
|
|
|
}
|
|
|
|
|
2012-11-30 15:21:02 +00:00
|
|
|
static int
|
|
|
|
mymain(void)
|
|
|
|
{
|
|
|
|
int ret = 0;
|
|
|
|
|
2017-11-03 12:09:47 +00:00
|
|
|
#define TEST_STREQ(aa, bb) \
|
|
|
|
do { \
|
|
|
|
struct testStreqData streqData = {.a = aa, .b = bb}; \
|
|
|
|
if (virTestRun("Streq", testStreq, &streqData) < 0) \
|
|
|
|
ret = -1; \
|
2016-12-09 10:52:28 +00:00
|
|
|
} while (0)
|
|
|
|
|
|
|
|
TEST_STREQ("hello", "world");
|
|
|
|
TEST_STREQ(NULL, NULL);
|
|
|
|
TEST_STREQ(NULL, "");
|
|
|
|
TEST_STREQ("", NULL);
|
|
|
|
TEST_STREQ("", "");
|
|
|
|
TEST_STREQ("hello", "hello");
|
|
|
|
|
2016-05-26 15:01:50 +00:00
|
|
|
if (virTestRun("virStringSortCompare", testStringSortCompare, NULL) < 0)
|
2013-11-28 11:14:59 +00:00
|
|
|
ret = -1;
|
|
|
|
|
2017-11-03 12:09:47 +00:00
|
|
|
#define TEST_SEARCH(s, r, x, n, m, e) \
|
|
|
|
do { \
|
|
|
|
struct stringSearchData data = { \
|
|
|
|
.str = s, \
|
|
|
|
.maxMatches = x, \
|
|
|
|
.regexp = r, \
|
|
|
|
.expectNMatches = n, \
|
|
|
|
.expectMatches = m, \
|
|
|
|
.expectError = e, \
|
|
|
|
}; \
|
2016-05-26 15:01:50 +00:00
|
|
|
if (virTestRun("virStringSearch " s, testStringSearch, &data) < 0) \
|
2017-11-03 12:09:47 +00:00
|
|
|
ret = -1; \
|
2014-01-23 09:28:29 +00:00
|
|
|
} while (0)
|
|
|
|
|
|
|
|
/* error due to missing () in regexp */
|
|
|
|
TEST_SEARCH("foo", "bar", 10, 0, NULL, true);
|
|
|
|
|
|
|
|
/* error due to too many () in regexp */
|
|
|
|
TEST_SEARCH("foo", "(b)(a)(r)", 10, 0, NULL, true);
|
|
|
|
|
|
|
|
/* None matching */
|
|
|
|
TEST_SEARCH("foo", "(bar)", 10, 0, NULL, false);
|
|
|
|
|
2020-08-03 15:32:22 +00:00
|
|
|
VIR_WARNINGS_NO_DECLARATION_AFTER_STATEMENT
|
2014-01-23 09:28:29 +00:00
|
|
|
/* Full match */
|
|
|
|
const char *matches1[] = { "foo" };
|
|
|
|
TEST_SEARCH("foo", "(foo)", 10, 1, matches1, false);
|
|
|
|
|
|
|
|
/* Multi matches */
|
|
|
|
const char *matches2[] = { "foo", "bar", "eek" };
|
|
|
|
TEST_SEARCH("1foo2bar3eek", "([a-z]+)", 10, 3, matches2, false);
|
|
|
|
|
|
|
|
/* Multi matches, limited returns */
|
|
|
|
const char *matches3[] = { "foo", "bar" };
|
|
|
|
TEST_SEARCH("1foo2bar3eek", "([a-z]+)", 2, 2, matches3, false);
|
2020-08-03 15:32:22 +00:00
|
|
|
VIR_WARNINGS_RESET
|
2014-01-23 09:28:29 +00:00
|
|
|
|
2017-11-03 12:09:47 +00:00
|
|
|
#define TEST_MATCH(s, r, m) \
|
|
|
|
do { \
|
|
|
|
struct stringMatchData data = { \
|
|
|
|
.str = s, \
|
|
|
|
.regexp = r, \
|
|
|
|
.expectMatch = m, \
|
|
|
|
}; \
|
|
|
|
if (virTestRun("virStringMatch " s, testStringMatch, &data) < 0) \
|
|
|
|
ret = -1; \
|
2017-05-11 15:16:13 +00:00
|
|
|
} while (0)
|
|
|
|
|
|
|
|
TEST_MATCH("foo", "foo", true);
|
|
|
|
TEST_MATCH("foobar", "f[o]+", true);
|
|
|
|
TEST_MATCH("foobar", "^f[o]+$", false);
|
|
|
|
|
2017-11-03 12:09:47 +00:00
|
|
|
#define TEST_REPLACE(h, o, n, r) \
|
|
|
|
do { \
|
|
|
|
struct stringReplaceData data = { \
|
|
|
|
.haystack = h, \
|
|
|
|
.oldneedle = o, \
|
|
|
|
.newneedle = n, \
|
|
|
|
.result = r \
|
|
|
|
}; \
|
2016-05-26 15:01:50 +00:00
|
|
|
if (virTestRun("virStringReplace " h, testStringReplace, &data) < 0) \
|
2017-11-03 12:09:47 +00:00
|
|
|
ret = -1; \
|
2014-02-19 20:30:46 +00:00
|
|
|
} while (0)
|
|
|
|
|
|
|
|
/* no matches */
|
|
|
|
TEST_REPLACE("foo", "bar", "eek", "foo");
|
|
|
|
|
|
|
|
/* complete match */
|
|
|
|
TEST_REPLACE("foo", "foo", "bar", "bar");
|
|
|
|
|
|
|
|
/* middle match */
|
|
|
|
TEST_REPLACE("foobarwizz", "bar", "eek", "fooeekwizz");
|
|
|
|
|
|
|
|
/* many matches */
|
|
|
|
TEST_REPLACE("foofoofoofoo", "foo", "bar", "barbarbarbar");
|
|
|
|
|
|
|
|
/* many matches */
|
|
|
|
TEST_REPLACE("fooooofoooo", "foo", "bar", "barooobaroo");
|
|
|
|
|
|
|
|
/* different length old/new needles */
|
|
|
|
TEST_REPLACE("fooooofoooo", "foo", "barwizzeek", "barwizzeekooobarwizzeekoo");
|
|
|
|
TEST_REPLACE("fooooofoooo", "foooo", "foo", "fooofoo");
|
|
|
|
|
2017-11-03 12:09:47 +00:00
|
|
|
#define TEST_STRTOL(str, suff, i, i_ret, u, u_ret, \
|
|
|
|
ll, ll_ret, ull, ull_ret) \
|
|
|
|
do { \
|
|
|
|
struct stringToLongData data = { \
|
|
|
|
str, suff, i, i_ret, u, u_ret, ll, ll_ret, ull, ull_ret, \
|
|
|
|
}; \
|
|
|
|
if (virTestRun("virStringToLong '" str "'", testStringToLong, \
|
|
|
|
&data) < 0) \
|
|
|
|
ret = -1; \
|
util: fix uint parsing on 64-bit platforms
Commit f22b7899 called to light a long-standing latent bug: the
behavior of virStrToLong_ui was different on 32-bit platforms
than on 64-bit platforms. Curse you, C type promotion and
narrowing rules, and strtoul specification. POSIX says that for
a 32-bit long, strtol handles only 2^32 values [LONG_MIN to
LONG_MAX] while strtoul handles 2^33 - 1 values [-ULONG_MAX to
ULONG_MAX] with twos-complement wraparound for negatives. Thus,
parsing -1 as unsigned long produces ULONG_MAX, rather than a
range error. We WANT[1] this same shortcut for turning -1 into
UINT_MAX when parsing to int; and get it for free with 32-bit
long. But with 64-bit long, ULONG_MAX is outside the range
of int and we were rejecting it as invalid; meanwhile, we were
silently treating -18446744073709551615 as 1 even though it
textually exceeds INT_MIN. Too bad there's not a strtoui() in
libc that does guaranteed parsing to int, regardless of the size
of long.
The bug has been latent since 2007, introduced by Jim Meyering
in commit 5d25419 in the attempt to eradicate unsafe use of
strto[u]l when parsing ints and longs. How embarrassing that we
are only discovering it now - so I'm adding a testsuite to ensure
that it covers all the corner cases we care about.
[1] Ideally, we really want the caller to be able to choose whether
to allow negative numbers to wrap around to their 2s-complement
counterpart, as in strtoul, or to force a stricter input range
of [0 to UINT_MAX] by rejecting negative signs; this will be added
in a later patch for all three int types.
This patch is tested on both 32- and 64-bit; the enhanced
virstringtest passes on both platforms, while virstoragetest now
reliably fails on both platforms instead of just 32-bit platforms.
That test will be fixed later.
* src/util/virstring.c (virStrToLong_ui): Ensure same behavior
regardless of platform long size.
* tests/virstringtest.c (testStringToLong): New function.
(mymain): Comprehensively test string to long parsing.
Signed-off-by: Eric Blake <eblake@redhat.com>
2014-04-30 20:46:18 +00:00
|
|
|
} while (0)
|
|
|
|
|
|
|
|
/* Start simple */
|
|
|
|
TEST_STRTOL("0", NULL, 0, 0, 0U, 0, 0LL, 0, 0ULL, 0);
|
|
|
|
|
|
|
|
/* All your base are belong to us */
|
|
|
|
TEST_STRTOL("0x0", NULL, 0, 0, 0U, 0, 0LL, 0, 0ULL, 0);
|
|
|
|
TEST_STRTOL("0XaB", NULL, 171, 0, 171U, 0, 171LL, 0, 171ULL, 0);
|
|
|
|
TEST_STRTOL("010", NULL, 8, 0, 8U, 0, 8LL, 0, 8ULL, 0);
|
|
|
|
|
|
|
|
/* Suffix handling */
|
|
|
|
TEST_STRTOL("42", NULL, 42, 0, 42U, 0, 42LL, 0, 42ULL, 0);
|
|
|
|
TEST_STRTOL("42", "", 42, 0, 42U, 0, 42LL, 0, 42ULL, 0);
|
|
|
|
TEST_STRTOL("42.", NULL, 0, -1, 0U, -1, 0LL, -1, 0ULL, -1);
|
|
|
|
TEST_STRTOL("42.", ".", 42, 0, 42U, 0, 42LL, 0, 42ULL, 0);
|
|
|
|
|
|
|
|
/* Blatant invalid input */
|
|
|
|
TEST_STRTOL("", "", 0, -1, 0U, -1, 0LL, -1, 0ULL, -1);
|
|
|
|
TEST_STRTOL("", NULL, 0, -1, 0U, -1, 0LL, -1, 0ULL, -1);
|
|
|
|
TEST_STRTOL(" ", " ", 0, -1, 0U, -1, 0LL, -1, 0ULL, -1);
|
|
|
|
TEST_STRTOL(" ", NULL, 0, -1, 0U, -1, 0LL, -1, 0ULL, -1);
|
|
|
|
TEST_STRTOL(" -", " -", 0, -1, 0U, -1, 0LL, -1, 0ULL, -1);
|
|
|
|
TEST_STRTOL(" -", NULL, 0, -1, 0U, -1, 0LL, -1, 0ULL, -1);
|
|
|
|
TEST_STRTOL("a", "a", 0, -1, 0U, -1, 0LL, -1, 0ULL, -1);
|
|
|
|
TEST_STRTOL("a", NULL, 0, -1, 0U, -1, 0LL, -1, 0ULL, -1);
|
|
|
|
|
|
|
|
/* Not a hex number, but valid when suffix expected */
|
|
|
|
TEST_STRTOL(" 0x", NULL, 0, -1, 0U, -1, 0LL, -1, 0ULL, -1);
|
|
|
|
TEST_STRTOL(" 0x", "x", 0, 0, 0U, 0, 0LL, 0, 0ULL, 0);
|
|
|
|
|
|
|
|
/* Upper bounds */
|
|
|
|
TEST_STRTOL("2147483647", NULL, 2147483647, 0, 2147483647U, 0,
|
|
|
|
2147483647LL, 0, 2147483647ULL, 0);
|
|
|
|
TEST_STRTOL("2147483648", NULL, 0, -1, 2147483648U, 0,
|
|
|
|
2147483648LL, 0, 2147483648ULL, 0);
|
|
|
|
TEST_STRTOL("4294967295", NULL, 0, -1, 4294967295U, 0,
|
|
|
|
4294967295LL, 0, 4294967295ULL, 0);
|
|
|
|
TEST_STRTOL("4294967296", NULL, 0, -1, 0U, -1,
|
|
|
|
4294967296LL, 0, 4294967296ULL, 0);
|
|
|
|
TEST_STRTOL("9223372036854775807", NULL, 0, -1, 0U, -1,
|
|
|
|
9223372036854775807LL, 0, 9223372036854775807ULL, 0);
|
|
|
|
TEST_STRTOL("9223372036854775808", NULL, 0, -1, 0U, -1,
|
|
|
|
0LL, -1, 9223372036854775808ULL, 0);
|
|
|
|
TEST_STRTOL("18446744073709551615", NULL, 0, -1, 0U, -1,
|
|
|
|
0LL, -1, 18446744073709551615ULL, 0);
|
|
|
|
TEST_STRTOL("18446744073709551616", NULL, 0, -1, 0U, -1,
|
|
|
|
0LL, -1, 0ULL, -1);
|
|
|
|
TEST_STRTOL("18446744073709551616", "", 0, -1, 0U, -1,
|
|
|
|
0LL, -1, 0ULL, -1);
|
|
|
|
|
|
|
|
/* Negative bounds */
|
|
|
|
TEST_STRTOL("-0", NULL, 0, 0, 0U, 0, 0LL, 0, 0ULL, 0);
|
|
|
|
TEST_STRTOL("-1", "", -1, 0, 4294967295U, 0,
|
|
|
|
-1LL, 0, 18446744073709551615ULL, 0);
|
|
|
|
TEST_STRTOL("-2147483647", NULL, -2147483647, 0, 2147483649U, 0,
|
|
|
|
-2147483647LL, 0, 18446744071562067969ULL, 0);
|
2014-05-30 22:30:07 +00:00
|
|
|
TEST_STRTOL("-2147483648", NULL, INT32_MIN, 0, 2147483648U, 0,
|
util: fix uint parsing on 64-bit platforms
Commit f22b7899 called to light a long-standing latent bug: the
behavior of virStrToLong_ui was different on 32-bit platforms
than on 64-bit platforms. Curse you, C type promotion and
narrowing rules, and strtoul specification. POSIX says that for
a 32-bit long, strtol handles only 2^32 values [LONG_MIN to
LONG_MAX] while strtoul handles 2^33 - 1 values [-ULONG_MAX to
ULONG_MAX] with twos-complement wraparound for negatives. Thus,
parsing -1 as unsigned long produces ULONG_MAX, rather than a
range error. We WANT[1] this same shortcut for turning -1 into
UINT_MAX when parsing to int; and get it for free with 32-bit
long. But with 64-bit long, ULONG_MAX is outside the range
of int and we were rejecting it as invalid; meanwhile, we were
silently treating -18446744073709551615 as 1 even though it
textually exceeds INT_MIN. Too bad there's not a strtoui() in
libc that does guaranteed parsing to int, regardless of the size
of long.
The bug has been latent since 2007, introduced by Jim Meyering
in commit 5d25419 in the attempt to eradicate unsafe use of
strto[u]l when parsing ints and longs. How embarrassing that we
are only discovering it now - so I'm adding a testsuite to ensure
that it covers all the corner cases we care about.
[1] Ideally, we really want the caller to be able to choose whether
to allow negative numbers to wrap around to their 2s-complement
counterpart, as in strtoul, or to force a stricter input range
of [0 to UINT_MAX] by rejecting negative signs; this will be added
in a later patch for all three int types.
This patch is tested on both 32- and 64-bit; the enhanced
virstringtest passes on both platforms, while virstoragetest now
reliably fails on both platforms instead of just 32-bit platforms.
That test will be fixed later.
* src/util/virstring.c (virStrToLong_ui): Ensure same behavior
regardless of platform long size.
* tests/virstringtest.c (testStringToLong): New function.
(mymain): Comprehensively test string to long parsing.
Signed-off-by: Eric Blake <eblake@redhat.com>
2014-04-30 20:46:18 +00:00
|
|
|
-2147483648LL, 0, 18446744071562067968ULL, 0);
|
|
|
|
TEST_STRTOL("-2147483649", NULL, 0, -1, 2147483647U, 0,
|
|
|
|
-2147483649LL, 0, 18446744071562067967ULL, 0);
|
|
|
|
TEST_STRTOL("-4294967295", NULL, 0, -1, 1U, 0,
|
|
|
|
-4294967295LL, 0, 18446744069414584321ULL, 0);
|
|
|
|
TEST_STRTOL("-4294967296", NULL, 0, -1, 0U, -1,
|
|
|
|
-4294967296LL, 0, 18446744069414584320ULL, 0);
|
|
|
|
TEST_STRTOL("-9223372036854775807", NULL, 0, -1, 0U, -1,
|
|
|
|
-9223372036854775807LL, 0, 9223372036854775809ULL, 0);
|
|
|
|
TEST_STRTOL("-9223372036854775808", NULL, 0, -1, 0U, -1,
|
2014-05-30 22:30:07 +00:00
|
|
|
INT64_MIN, 0, 9223372036854775808ULL, 0);
|
util: fix uint parsing on 64-bit platforms
Commit f22b7899 called to light a long-standing latent bug: the
behavior of virStrToLong_ui was different on 32-bit platforms
than on 64-bit platforms. Curse you, C type promotion and
narrowing rules, and strtoul specification. POSIX says that for
a 32-bit long, strtol handles only 2^32 values [LONG_MIN to
LONG_MAX] while strtoul handles 2^33 - 1 values [-ULONG_MAX to
ULONG_MAX] with twos-complement wraparound for negatives. Thus,
parsing -1 as unsigned long produces ULONG_MAX, rather than a
range error. We WANT[1] this same shortcut for turning -1 into
UINT_MAX when parsing to int; and get it for free with 32-bit
long. But with 64-bit long, ULONG_MAX is outside the range
of int and we were rejecting it as invalid; meanwhile, we were
silently treating -18446744073709551615 as 1 even though it
textually exceeds INT_MIN. Too bad there's not a strtoui() in
libc that does guaranteed parsing to int, regardless of the size
of long.
The bug has been latent since 2007, introduced by Jim Meyering
in commit 5d25419 in the attempt to eradicate unsafe use of
strto[u]l when parsing ints and longs. How embarrassing that we
are only discovering it now - so I'm adding a testsuite to ensure
that it covers all the corner cases we care about.
[1] Ideally, we really want the caller to be able to choose whether
to allow negative numbers to wrap around to their 2s-complement
counterpart, as in strtoul, or to force a stricter input range
of [0 to UINT_MAX] by rejecting negative signs; this will be added
in a later patch for all three int types.
This patch is tested on both 32- and 64-bit; the enhanced
virstringtest passes on both platforms, while virstoragetest now
reliably fails on both platforms instead of just 32-bit platforms.
That test will be fixed later.
* src/util/virstring.c (virStrToLong_ui): Ensure same behavior
regardless of platform long size.
* tests/virstringtest.c (testStringToLong): New function.
(mymain): Comprehensively test string to long parsing.
Signed-off-by: Eric Blake <eblake@redhat.com>
2014-04-30 20:46:18 +00:00
|
|
|
TEST_STRTOL("-9223372036854775809", NULL, 0, -1, 0U, -1,
|
|
|
|
0LL, -1, 9223372036854775807ULL, 0);
|
|
|
|
TEST_STRTOL("-18446744073709551615", NULL, 0, -1, 0U, -1,
|
|
|
|
0LL, -1, 1ULL, 0);
|
|
|
|
TEST_STRTOL("-18446744073709551616", NULL, 0, -1, 0U, -1,
|
|
|
|
0LL, -1, 0ULL, -1);
|
|
|
|
|
2017-11-03 12:09:47 +00:00
|
|
|
#define TEST_STRTOD(str, end_ptr, res) \
|
|
|
|
do { \
|
|
|
|
struct stringToDoubleData data = { \
|
|
|
|
str, end_ptr, res, \
|
|
|
|
}; \
|
|
|
|
if (virTestRun("virStringToDouble '" str "'", \
|
|
|
|
testStringToDouble, &data) < 0) \
|
|
|
|
ret = -1; \
|
2017-07-09 23:05:55 +00:00
|
|
|
} while (0)
|
|
|
|
|
|
|
|
/* Simple numbers. */
|
|
|
|
TEST_STRTOD("0.0", NULL, 0);
|
|
|
|
TEST_STRTOD("1.0", NULL, 1);
|
|
|
|
TEST_STRTOD("3.14159", NULL, 3.14159);
|
|
|
|
TEST_STRTOD("0.57721", NULL, 0.57721);
|
|
|
|
|
|
|
|
/* Testing ending string. */
|
|
|
|
TEST_STRTOD("2.718", "", 2.718);
|
|
|
|
TEST_STRTOD("2.718 281 828 459", " 281 828 459", 2.718);
|
|
|
|
TEST_STRTOD("2.718,281,828,459", ",281,828,459", 2.718);
|
|
|
|
|
|
|
|
/* Scientific numbers. */
|
|
|
|
TEST_STRTOD("3.14159e+000", NULL, 3.14159);
|
|
|
|
TEST_STRTOD("2.00600e+003", NULL, 2006);
|
|
|
|
TEST_STRTOD("1.00000e-010", NULL, 1e-010);
|
|
|
|
|
|
|
|
/* Negative numbers. */
|
|
|
|
TEST_STRTOD("-1.6180339887", NULL, -1.6180339887);
|
|
|
|
TEST_STRTOD("-0.00031e-010", NULL, -0.00031e-010);
|
|
|
|
|
|
|
|
/* Long numbers. */
|
|
|
|
TEST_STRTOD("57089907708238388904078437636832797971793838081897.0",
|
|
|
|
NULL,
|
|
|
|
57089907708238388904078437636832797971793838081897.0);
|
|
|
|
TEST_STRTOD("3.141592653589793238462643383279502884197169399375105",
|
|
|
|
NULL,
|
|
|
|
3.141592653589793238462643383279502884197169399375105);
|
|
|
|
|
2017-11-03 12:09:47 +00:00
|
|
|
#define TEST_STRIP_IPV6_BRACKETS(str, res) \
|
|
|
|
do { \
|
|
|
|
struct testStripData stripData = { \
|
|
|
|
.string = str, \
|
|
|
|
.result = res, \
|
|
|
|
}; \
|
|
|
|
if (virTestRun("Strip brackets from IPv6 " #str, \
|
|
|
|
testStripIPv6Brackets, &stripData) < 0) \
|
|
|
|
ret = -1; \
|
2014-10-07 15:27:40 +00:00
|
|
|
} while (0)
|
|
|
|
|
|
|
|
TEST_STRIP_IPV6_BRACKETS(NULL, NULL);
|
|
|
|
TEST_STRIP_IPV6_BRACKETS("[]", "[]");
|
|
|
|
TEST_STRIP_IPV6_BRACKETS("[:]", ":");
|
|
|
|
TEST_STRIP_IPV6_BRACKETS("[::1]", "::1");
|
|
|
|
TEST_STRIP_IPV6_BRACKETS("[hello:", "[hello:");
|
|
|
|
TEST_STRIP_IPV6_BRACKETS(":hello]", ":hello]");
|
|
|
|
TEST_STRIP_IPV6_BRACKETS(":[]:", ":[]:");
|
|
|
|
|
2017-11-03 12:09:47 +00:00
|
|
|
#define TEST_STRIP_CONTROL_CHARS(str, res) \
|
|
|
|
do { \
|
|
|
|
struct testStripData stripData = { \
|
|
|
|
.string = str, \
|
|
|
|
.result = res, \
|
|
|
|
}; \
|
|
|
|
if (virTestRun("Strip control chars from " #str, \
|
|
|
|
testStripControlChars, &stripData) < 0) \
|
|
|
|
ret = -1; \
|
2015-04-14 10:30:16 +00:00
|
|
|
} while (0)
|
|
|
|
|
|
|
|
TEST_STRIP_CONTROL_CHARS(NULL, NULL);
|
|
|
|
TEST_STRIP_CONTROL_CHARS("\nhello \r hello\t", "\nhello \r hello\t");
|
|
|
|
TEST_STRIP_CONTROL_CHARS("\x01H\x02" "E\x03L\x04L\x05O", "HELLO");
|
|
|
|
TEST_STRIP_CONTROL_CHARS("\x01\x02\x03\x04HELL\x05O", "HELLO");
|
|
|
|
TEST_STRIP_CONTROL_CHARS("\nhello \x01\x07hello\t", "\nhello hello\t");
|
2017-12-18 14:46:53 +00:00
|
|
|
|
|
|
|
#define TEST_FILTER_CHARS(str, filter, res) \
|
|
|
|
do { \
|
|
|
|
struct testFilterData filterData = { \
|
2018-01-04 08:29:49 +00:00
|
|
|
.string = str, \
|
2017-12-18 14:46:53 +00:00
|
|
|
.valid = filter, \
|
2018-01-04 08:29:49 +00:00
|
|
|
.result = res, \
|
2017-12-18 14:46:53 +00:00
|
|
|
}; \
|
|
|
|
if (virTestRun("Filter chars from " #str, \
|
|
|
|
testFilterChars, &filterData) < 0) \
|
|
|
|
ret = -1; \
|
|
|
|
} while (0)
|
|
|
|
|
|
|
|
TEST_FILTER_CHARS(NULL, NULL, NULL);
|
|
|
|
TEST_FILTER_CHARS("hello 123 hello", "helo", "hellohello");
|
|
|
|
|
2014-03-17 09:38:38 +00:00
|
|
|
return ret == 0 ? EXIT_SUCCESS : EXIT_FAILURE;
|
2012-11-30 15:21:02 +00:00
|
|
|
}
|
|
|
|
|
2017-03-29 14:45:42 +00:00
|
|
|
VIR_TEST_MAIN(mymain)
|