2007-01-08 01:04:40 +03:00
|
|
|
/*
|
|
|
|
* Simple C functions to supplement the C library
|
2007-09-17 01:08:06 +04:00
|
|
|
*
|
2007-01-08 01:04:40 +03:00
|
|
|
* Copyright (c) 2006 Fabrice Bellard
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
|
|
* of this software and associated documentation files (the "Software"), to deal
|
|
|
|
* in the Software without restriction, including without limitation the rights
|
|
|
|
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
|
|
* copies of the Software, and to permit persons to whom the Software is
|
|
|
|
* furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice shall be included in
|
|
|
|
* all copies or substantial portions of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
|
|
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
|
|
|
|
* THE SOFTWARE.
|
|
|
|
*/
|
2019-05-23 17:35:06 +03:00
|
|
|
|
2016-01-29 20:49:55 +03:00
|
|
|
#include "qemu/osdep.h"
|
2012-12-17 21:20:00 +04:00
|
|
|
#include "qemu/host-utils.h"
|
2010-10-21 19:15:46 +04:00
|
|
|
#include <math.h>
|
2007-01-08 01:04:40 +03:00
|
|
|
|
2022-05-25 17:41:26 +03:00
|
|
|
#ifdef __FreeBSD__
|
|
|
|
#include <sys/sysctl.h>
|
|
|
|
#include <sys/user.h>
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifdef __NetBSD__
|
|
|
|
#include <sys/sysctl.h>
|
|
|
|
#endif
|
|
|
|
|
2022-07-18 19:42:11 +03:00
|
|
|
#ifdef __HAIKU__
|
|
|
|
#include <kernel/image.h>
|
|
|
|
#endif
|
|
|
|
|
2022-08-10 01:20:46 +03:00
|
|
|
#ifdef __APPLE__
|
|
|
|
#include <mach-o/dyld.h>
|
|
|
|
#endif
|
|
|
|
|
2022-06-24 17:50:37 +03:00
|
|
|
#ifdef G_OS_WIN32
|
|
|
|
#include <pathcch.h>
|
|
|
|
#include <wchar.h>
|
|
|
|
#endif
|
|
|
|
|
2019-05-23 17:35:06 +03:00
|
|
|
#include "qemu/ctype.h"
|
2016-03-20 20:16:19 +03:00
|
|
|
#include "qemu/cutils.h"
|
2017-08-18 21:47:35 +03:00
|
|
|
#include "qemu/error-report.h"
|
2011-09-08 15:46:25 +04:00
|
|
|
|
2012-07-09 10:50:43 +04:00
|
|
|
void strpadcpy(char *buf, int buf_size, const char *str, char pad)
|
|
|
|
{
|
|
|
|
int len = qemu_strnlen(str, buf_size);
|
|
|
|
memcpy(buf, str, len);
|
|
|
|
memset(buf + len, pad, buf_size - len);
|
|
|
|
}
|
|
|
|
|
2007-01-08 01:04:40 +03:00
|
|
|
void pstrcpy(char *buf, int buf_size, const char *str)
|
|
|
|
{
|
|
|
|
int c;
|
|
|
|
char *q = buf;
|
|
|
|
|
|
|
|
if (buf_size <= 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
for(;;) {
|
|
|
|
c = *str++;
|
|
|
|
if (c == 0 || q >= buf + buf_size - 1)
|
|
|
|
break;
|
|
|
|
*q++ = c;
|
|
|
|
}
|
|
|
|
*q = '\0';
|
|
|
|
}
|
|
|
|
|
|
|
|
/* strcat and truncate. */
|
|
|
|
char *pstrcat(char *buf, int buf_size, const char *s)
|
|
|
|
{
|
|
|
|
int len;
|
|
|
|
len = strlen(buf);
|
2007-09-17 01:08:06 +04:00
|
|
|
if (len < buf_size)
|
2007-01-08 01:04:40 +03:00
|
|
|
pstrcpy(buf + len, buf_size - len, s);
|
|
|
|
return buf;
|
|
|
|
}
|
|
|
|
|
|
|
|
int strstart(const char *str, const char *val, const char **ptr)
|
|
|
|
{
|
|
|
|
const char *p, *q;
|
|
|
|
p = str;
|
|
|
|
q = val;
|
|
|
|
while (*q != '\0') {
|
|
|
|
if (*p != *q)
|
|
|
|
return 0;
|
|
|
|
p++;
|
|
|
|
q++;
|
|
|
|
}
|
|
|
|
if (ptr)
|
|
|
|
*ptr = p;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
int stristart(const char *str, const char *val, const char **ptr)
|
|
|
|
{
|
|
|
|
const char *p, *q;
|
|
|
|
p = str;
|
|
|
|
q = val;
|
|
|
|
while (*q != '\0') {
|
2008-11-16 16:53:32 +03:00
|
|
|
if (qemu_toupper(*p) != qemu_toupper(*q))
|
2007-01-08 01:04:40 +03:00
|
|
|
return 0;
|
|
|
|
p++;
|
|
|
|
q++;
|
|
|
|
}
|
|
|
|
if (ptr)
|
|
|
|
*ptr = p;
|
|
|
|
return 1;
|
|
|
|
}
|
2007-11-10 22:36:39 +03:00
|
|
|
|
2009-07-01 22:24:44 +04:00
|
|
|
/* XXX: use host strnlen if available ? */
|
|
|
|
int qemu_strnlen(const char *s, int max_len)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for(i = 0; i < max_len; i++) {
|
|
|
|
if (s[i] == '\0') {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return i;
|
|
|
|
}
|
|
|
|
|
2013-06-05 16:19:35 +04:00
|
|
|
char *qemu_strsep(char **input, const char *delim)
|
|
|
|
{
|
|
|
|
char *result = *input;
|
|
|
|
if (result != NULL) {
|
|
|
|
char *p;
|
|
|
|
|
|
|
|
for (p = result; *p != '\0'; p++) {
|
|
|
|
if (strchr(delim, *p)) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (*p == '\0') {
|
|
|
|
*input = NULL;
|
|
|
|
} else {
|
|
|
|
*p = '\0';
|
|
|
|
*input = p + 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2007-11-10 22:36:39 +03:00
|
|
|
time_t mktimegm(struct tm *tm)
|
|
|
|
{
|
|
|
|
time_t t;
|
|
|
|
int y = tm->tm_year + 1900, m = tm->tm_mon + 1, d = tm->tm_mday;
|
|
|
|
if (m < 3) {
|
|
|
|
m += 12;
|
|
|
|
y--;
|
|
|
|
}
|
2012-10-01 16:22:06 +04:00
|
|
|
t = 86400ULL * (d + (153 * m - 457) / 5 + 365 * y + y / 4 - y / 100 +
|
2007-11-10 22:36:39 +03:00
|
|
|
y / 400 - 719469);
|
|
|
|
t += 3600 * tm->tm_hour + 60 * tm->tm_min + tm->tm_sec;
|
|
|
|
return t;
|
|
|
|
}
|
2008-12-04 22:19:45 +03:00
|
|
|
|
cutils: Make strtosz & friends leave follow set to callers
strtosz() & friends require the size to be at the end of the string,
or be followed by whitespace or ','. I find this surprising, because
the name suggests it works like strtol().
The check simplifies callers that accept exactly that follow set
slightly. No such callers exist.
The check is redundant for callers that accept a smaller follow set,
and thus need to check themselves anyway. Right now, this is the case
for all but one caller. All of them neglected to check, or checked
incorrectly, but the previous few commits fixed them up.
Finally, the check is problematic for callers that accept a larger
follow set. This is the case in monitor_parse_command().
Fortunately, the problems there are relatively harmless.
monitor_parse_command() uses strtosz() for argument type 'o'. When
the last argument is of type 'o', a trailing ',' is diagnosed
differently than other trailing junk:
(qemu) migrate_set_speed 1x
invalid size
(qemu) migrate_set_speed 1,
migrate_set_speed: extraneous characters at the end of line
A related inconsistency exists with non-last arguments. No such
command exists, but let's use memsave to explore the inconsistency.
The monitor permits, but does not require whitespace between
arguments. For instance, "memsave (1-1)1024foo" is parsed as command
memsave with three arguments 0, 1024 and "foo". Yes, this is daft,
but at least it's consistently daft.
If I change memsave's second argument from 'i' to 'o', then "memsave
(1-1)1foo" is rejected, because the size is followed by an 'f'. But
"memsave (1-1)1," is still accepted, and duly saves to file ",".
We don't have any users of strtosz that profit from the check. In the
users we have, it appears to encourage sloppy error checking, or gets
in the way. Drop the bothersome check.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-11-22 12:46:06 +04:00
|
|
|
static int64_t suffix_mul(char suffix, int64_t unit)
|
|
|
|
{
|
|
|
|
switch (qemu_toupper(suffix)) {
|
2017-02-21 23:14:01 +03:00
|
|
|
case 'B':
|
cutils: Make strtosz & friends leave follow set to callers
strtosz() & friends require the size to be at the end of the string,
or be followed by whitespace or ','. I find this surprising, because
the name suggests it works like strtol().
The check simplifies callers that accept exactly that follow set
slightly. No such callers exist.
The check is redundant for callers that accept a smaller follow set,
and thus need to check themselves anyway. Right now, this is the case
for all but one caller. All of them neglected to check, or checked
incorrectly, but the previous few commits fixed them up.
Finally, the check is problematic for callers that accept a larger
follow set. This is the case in monitor_parse_command().
Fortunately, the problems there are relatively harmless.
monitor_parse_command() uses strtosz() for argument type 'o'. When
the last argument is of type 'o', a trailing ',' is diagnosed
differently than other trailing junk:
(qemu) migrate_set_speed 1x
invalid size
(qemu) migrate_set_speed 1,
migrate_set_speed: extraneous characters at the end of line
A related inconsistency exists with non-last arguments. No such
command exists, but let's use memsave to explore the inconsistency.
The monitor permits, but does not require whitespace between
arguments. For instance, "memsave (1-1)1024foo" is parsed as command
memsave with three arguments 0, 1024 and "foo". Yes, this is daft,
but at least it's consistently daft.
If I change memsave's second argument from 'i' to 'o', then "memsave
(1-1)1foo" is rejected, because the size is followed by an 'f'. But
"memsave (1-1)1," is still accepted, and duly saves to file ",".
We don't have any users of strtosz that profit from the check. In the
users we have, it appears to encourage sloppy error checking, or gets
in the way. Drop the bothersome check.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-11-22 12:46:06 +04:00
|
|
|
return 1;
|
2017-02-21 23:14:01 +03:00
|
|
|
case 'K':
|
cutils: Make strtosz & friends leave follow set to callers
strtosz() & friends require the size to be at the end of the string,
or be followed by whitespace or ','. I find this surprising, because
the name suggests it works like strtol().
The check simplifies callers that accept exactly that follow set
slightly. No such callers exist.
The check is redundant for callers that accept a smaller follow set,
and thus need to check themselves anyway. Right now, this is the case
for all but one caller. All of them neglected to check, or checked
incorrectly, but the previous few commits fixed them up.
Finally, the check is problematic for callers that accept a larger
follow set. This is the case in monitor_parse_command().
Fortunately, the problems there are relatively harmless.
monitor_parse_command() uses strtosz() for argument type 'o'. When
the last argument is of type 'o', a trailing ',' is diagnosed
differently than other trailing junk:
(qemu) migrate_set_speed 1x
invalid size
(qemu) migrate_set_speed 1,
migrate_set_speed: extraneous characters at the end of line
A related inconsistency exists with non-last arguments. No such
command exists, but let's use memsave to explore the inconsistency.
The monitor permits, but does not require whitespace between
arguments. For instance, "memsave (1-1)1024foo" is parsed as command
memsave with three arguments 0, 1024 and "foo". Yes, this is daft,
but at least it's consistently daft.
If I change memsave's second argument from 'i' to 'o', then "memsave
(1-1)1foo" is rejected, because the size is followed by an 'f'. But
"memsave (1-1)1," is still accepted, and duly saves to file ",".
We don't have any users of strtosz that profit from the check. In the
users we have, it appears to encourage sloppy error checking, or gets
in the way. Drop the bothersome check.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-11-22 12:46:06 +04:00
|
|
|
return unit;
|
2017-02-21 23:14:01 +03:00
|
|
|
case 'M':
|
cutils: Make strtosz & friends leave follow set to callers
strtosz() & friends require the size to be at the end of the string,
or be followed by whitespace or ','. I find this surprising, because
the name suggests it works like strtol().
The check simplifies callers that accept exactly that follow set
slightly. No such callers exist.
The check is redundant for callers that accept a smaller follow set,
and thus need to check themselves anyway. Right now, this is the case
for all but one caller. All of them neglected to check, or checked
incorrectly, but the previous few commits fixed them up.
Finally, the check is problematic for callers that accept a larger
follow set. This is the case in monitor_parse_command().
Fortunately, the problems there are relatively harmless.
monitor_parse_command() uses strtosz() for argument type 'o'. When
the last argument is of type 'o', a trailing ',' is diagnosed
differently than other trailing junk:
(qemu) migrate_set_speed 1x
invalid size
(qemu) migrate_set_speed 1,
migrate_set_speed: extraneous characters at the end of line
A related inconsistency exists with non-last arguments. No such
command exists, but let's use memsave to explore the inconsistency.
The monitor permits, but does not require whitespace between
arguments. For instance, "memsave (1-1)1024foo" is parsed as command
memsave with three arguments 0, 1024 and "foo". Yes, this is daft,
but at least it's consistently daft.
If I change memsave's second argument from 'i' to 'o', then "memsave
(1-1)1foo" is rejected, because the size is followed by an 'f'. But
"memsave (1-1)1," is still accepted, and duly saves to file ",".
We don't have any users of strtosz that profit from the check. In the
users we have, it appears to encourage sloppy error checking, or gets
in the way. Drop the bothersome check.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-11-22 12:46:06 +04:00
|
|
|
return unit * unit;
|
2017-02-21 23:14:01 +03:00
|
|
|
case 'G':
|
cutils: Make strtosz & friends leave follow set to callers
strtosz() & friends require the size to be at the end of the string,
or be followed by whitespace or ','. I find this surprising, because
the name suggests it works like strtol().
The check simplifies callers that accept exactly that follow set
slightly. No such callers exist.
The check is redundant for callers that accept a smaller follow set,
and thus need to check themselves anyway. Right now, this is the case
for all but one caller. All of them neglected to check, or checked
incorrectly, but the previous few commits fixed them up.
Finally, the check is problematic for callers that accept a larger
follow set. This is the case in monitor_parse_command().
Fortunately, the problems there are relatively harmless.
monitor_parse_command() uses strtosz() for argument type 'o'. When
the last argument is of type 'o', a trailing ',' is diagnosed
differently than other trailing junk:
(qemu) migrate_set_speed 1x
invalid size
(qemu) migrate_set_speed 1,
migrate_set_speed: extraneous characters at the end of line
A related inconsistency exists with non-last arguments. No such
command exists, but let's use memsave to explore the inconsistency.
The monitor permits, but does not require whitespace between
arguments. For instance, "memsave (1-1)1024foo" is parsed as command
memsave with three arguments 0, 1024 and "foo". Yes, this is daft,
but at least it's consistently daft.
If I change memsave's second argument from 'i' to 'o', then "memsave
(1-1)1foo" is rejected, because the size is followed by an 'f'. But
"memsave (1-1)1," is still accepted, and duly saves to file ",".
We don't have any users of strtosz that profit from the check. In the
users we have, it appears to encourage sloppy error checking, or gets
in the way. Drop the bothersome check.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-11-22 12:46:06 +04:00
|
|
|
return unit * unit * unit;
|
2017-02-21 23:14:01 +03:00
|
|
|
case 'T':
|
cutils: Make strtosz & friends leave follow set to callers
strtosz() & friends require the size to be at the end of the string,
or be followed by whitespace or ','. I find this surprising, because
the name suggests it works like strtol().
The check simplifies callers that accept exactly that follow set
slightly. No such callers exist.
The check is redundant for callers that accept a smaller follow set,
and thus need to check themselves anyway. Right now, this is the case
for all but one caller. All of them neglected to check, or checked
incorrectly, but the previous few commits fixed them up.
Finally, the check is problematic for callers that accept a larger
follow set. This is the case in monitor_parse_command().
Fortunately, the problems there are relatively harmless.
monitor_parse_command() uses strtosz() for argument type 'o'. When
the last argument is of type 'o', a trailing ',' is diagnosed
differently than other trailing junk:
(qemu) migrate_set_speed 1x
invalid size
(qemu) migrate_set_speed 1,
migrate_set_speed: extraneous characters at the end of line
A related inconsistency exists with non-last arguments. No such
command exists, but let's use memsave to explore the inconsistency.
The monitor permits, but does not require whitespace between
arguments. For instance, "memsave (1-1)1024foo" is parsed as command
memsave with three arguments 0, 1024 and "foo". Yes, this is daft,
but at least it's consistently daft.
If I change memsave's second argument from 'i' to 'o', then "memsave
(1-1)1foo" is rejected, because the size is followed by an 'f'. But
"memsave (1-1)1," is still accepted, and duly saves to file ",".
We don't have any users of strtosz that profit from the check. In the
users we have, it appears to encourage sloppy error checking, or gets
in the way. Drop the bothersome check.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-11-22 12:46:06 +04:00
|
|
|
return unit * unit * unit * unit;
|
2017-02-21 23:14:01 +03:00
|
|
|
case 'P':
|
2013-06-05 16:19:27 +04:00
|
|
|
return unit * unit * unit * unit * unit;
|
2017-02-21 23:14:01 +03:00
|
|
|
case 'E':
|
2013-06-05 16:19:27 +04:00
|
|
|
return unit * unit * unit * unit * unit * unit;
|
cutils: Make strtosz & friends leave follow set to callers
strtosz() & friends require the size to be at the end of the string,
or be followed by whitespace or ','. I find this surprising, because
the name suggests it works like strtol().
The check simplifies callers that accept exactly that follow set
slightly. No such callers exist.
The check is redundant for callers that accept a smaller follow set,
and thus need to check themselves anyway. Right now, this is the case
for all but one caller. All of them neglected to check, or checked
incorrectly, but the previous few commits fixed them up.
Finally, the check is problematic for callers that accept a larger
follow set. This is the case in monitor_parse_command().
Fortunately, the problems there are relatively harmless.
monitor_parse_command() uses strtosz() for argument type 'o'. When
the last argument is of type 'o', a trailing ',' is diagnosed
differently than other trailing junk:
(qemu) migrate_set_speed 1x
invalid size
(qemu) migrate_set_speed 1,
migrate_set_speed: extraneous characters at the end of line
A related inconsistency exists with non-last arguments. No such
command exists, but let's use memsave to explore the inconsistency.
The monitor permits, but does not require whitespace between
arguments. For instance, "memsave (1-1)1024foo" is parsed as command
memsave with three arguments 0, 1024 and "foo". Yes, this is daft,
but at least it's consistently daft.
If I change memsave's second argument from 'i' to 'o', then "memsave
(1-1)1foo" is rejected, because the size is followed by an 'f'. But
"memsave (1-1)1," is still accepted, and duly saves to file ",".
We don't have any users of strtosz that profit from the check. In the
users we have, it appears to encourage sloppy error checking, or gets
in the way. Drop the bothersome check.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-11-22 12:46:06 +04:00
|
|
|
}
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2010-10-21 19:15:46 +04:00
|
|
|
/*
|
utils: Improve qemu_strtosz() to have 64 bits of precision
We have multiple clients of qemu_strtosz (qemu-io, the opts visitor,
the keyval visitor), and it gets annoying that edge-case testing is
impacted by implicit rounding to 53 bits of precision due to parsing
with strtod(). As an example posted by Rich Jones:
$ nbdkit memory $(( 2**63 - 2**30 )) --run \
'build/qemu-io -f raw "$uri" -c "w -P 3 $(( 2**63 - 2**30 - 512 )) 512" '
write failed: Input/output error
because 9223372035781033472 got rounded to 0x7fffffffc0000000 which is
out of bounds.
It is also worth noting that our existing parser, by virtue of using
strtod(), accepts decimal AND hex numbers, even though test-cutils
previously lacked any coverage of the latter until the previous patch.
We do have existing clients that expect a hex parse to work (for
example, iotest 33 using qemu-io -c "write -P 0xa 0x200 0x400"), but
strtod() parses "08" as 8 rather than as an invalid octal number, so
we know there are no clients that depend on octal. Our use of
strtod() also means that "0x1.8k" would actually parse as 1536 (the
fraction is 8/16), rather than 1843 (if the fraction were 8/10); but
as this was not covered in the testsuite, I have no qualms forbidding
hex fractions as invalid, so this patch declares that the use of
fractions is only supported with decimal input, and enhances the
testsuite to document that.
Our previous use of strtod() meant that -1 parsed as a negative; now
that we parse with strtoull(), negative values can wrap around modulo
2^64, so we have to explicitly check whether the user passed in a '-';
and make it consistent to also reject '-0'. This has the minor effect
of treating negative values as EINVAL (with no change to endptr)
rather than ERANGE (with endptr advanced to what was parsed), visible
in the updated iotest output.
We also had no testsuite coverage of "1.1e0k", which happened to parse
under strtod() but is unlikely to occur in practice; as long as we are
making things more robust, it is easy enough to reject the use of
exponents in a strtod parse.
The fix is done by breaking the parse into an integer prefix (no loss
in precision), rejecting negative values (since we can no longer rely
on strtod() to do that), determining if a decimal or hexadecimal parse
was intended (with the new restriction that a fractional hex parse is
not allowed), and where appropriate, using a floating point fractional
parse (where we also scan to reject use of exponents in the fraction).
The bulk of the patch is then updates to the testsuite to match our
new precision, as well as adding new cases we reject (whether they
were rejected or inadvertently accepted before).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20210211204438.1184395-3-eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 23:44:36 +03:00
|
|
|
* Convert size string to bytes.
|
|
|
|
*
|
|
|
|
* The size parsing supports the following syntaxes
|
|
|
|
* - 12345 - decimal, scale determined by @default_suffix and @unit
|
|
|
|
* - 12345{bBkKmMgGtTpPeE} - decimal, scale determined by suffix and @unit
|
|
|
|
* - 12345.678{kKmMgGtTpPeE} - decimal, scale determined by suffix, and
|
2023-05-22 22:04:41 +03:00
|
|
|
* fractional portion is truncated to byte, either side of . may be empty
|
utils: Improve qemu_strtosz() to have 64 bits of precision
We have multiple clients of qemu_strtosz (qemu-io, the opts visitor,
the keyval visitor), and it gets annoying that edge-case testing is
impacted by implicit rounding to 53 bits of precision due to parsing
with strtod(). As an example posted by Rich Jones:
$ nbdkit memory $(( 2**63 - 2**30 )) --run \
'build/qemu-io -f raw "$uri" -c "w -P 3 $(( 2**63 - 2**30 - 512 )) 512" '
write failed: Input/output error
because 9223372035781033472 got rounded to 0x7fffffffc0000000 which is
out of bounds.
It is also worth noting that our existing parser, by virtue of using
strtod(), accepts decimal AND hex numbers, even though test-cutils
previously lacked any coverage of the latter until the previous patch.
We do have existing clients that expect a hex parse to work (for
example, iotest 33 using qemu-io -c "write -P 0xa 0x200 0x400"), but
strtod() parses "08" as 8 rather than as an invalid octal number, so
we know there are no clients that depend on octal. Our use of
strtod() also means that "0x1.8k" would actually parse as 1536 (the
fraction is 8/16), rather than 1843 (if the fraction were 8/10); but
as this was not covered in the testsuite, I have no qualms forbidding
hex fractions as invalid, so this patch declares that the use of
fractions is only supported with decimal input, and enhances the
testsuite to document that.
Our previous use of strtod() meant that -1 parsed as a negative; now
that we parse with strtoull(), negative values can wrap around modulo
2^64, so we have to explicitly check whether the user passed in a '-';
and make it consistent to also reject '-0'. This has the minor effect
of treating negative values as EINVAL (with no change to endptr)
rather than ERANGE (with endptr advanced to what was parsed), visible
in the updated iotest output.
We also had no testsuite coverage of "1.1e0k", which happened to parse
under strtod() but is unlikely to occur in practice; as long as we are
making things more robust, it is easy enough to reject the use of
exponents in a strtod parse.
The fix is done by breaking the parse into an integer prefix (no loss
in precision), rejecting negative values (since we can no longer rely
on strtod() to do that), determining if a decimal or hexadecimal parse
was intended (with the new restriction that a fractional hex parse is
not allowed), and where appropriate, using a floating point fractional
parse (where we also scan to reject use of exponents in the fraction).
The bulk of the patch is then updates to the testsuite to match our
new precision, as well as adding new cases we reject (whether they
were rejected or inadvertently accepted before).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20210211204438.1184395-3-eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 23:44:36 +03:00
|
|
|
* - 0x7fEE - hexadecimal, unit determined by @default_suffix
|
|
|
|
*
|
|
|
|
* The following are intentionally not supported
|
2023-05-22 22:04:41 +03:00
|
|
|
* - hex with scaling suffix, such as 0x20M or 0x1p3 (both fail with
|
|
|
|
* -EINVAL), while 0x1b is 27 (not 1 with byte scale)
|
|
|
|
* - octal, such as 08 (parsed as decimal instead)
|
|
|
|
* - binary, such as 0b1000 (parsed as 0b with trailing garbage "1000")
|
|
|
|
* - fractional hex, such as 0x1.8 (parsed as 0 with trailing garbage "x1.8")
|
|
|
|
* - negative values, including -0 (fail with -ERANGE)
|
|
|
|
* - floating point exponents, such as 1e3 (parsed as 1e with trailing
|
|
|
|
* garbage "3") or 0x1p3 (rejected as hex with scaling suffix)
|
|
|
|
* - non-finite values, such as inf or NaN (fail with -EINVAL)
|
utils: Improve qemu_strtosz() to have 64 bits of precision
We have multiple clients of qemu_strtosz (qemu-io, the opts visitor,
the keyval visitor), and it gets annoying that edge-case testing is
impacted by implicit rounding to 53 bits of precision due to parsing
with strtod(). As an example posted by Rich Jones:
$ nbdkit memory $(( 2**63 - 2**30 )) --run \
'build/qemu-io -f raw "$uri" -c "w -P 3 $(( 2**63 - 2**30 - 512 )) 512" '
write failed: Input/output error
because 9223372035781033472 got rounded to 0x7fffffffc0000000 which is
out of bounds.
It is also worth noting that our existing parser, by virtue of using
strtod(), accepts decimal AND hex numbers, even though test-cutils
previously lacked any coverage of the latter until the previous patch.
We do have existing clients that expect a hex parse to work (for
example, iotest 33 using qemu-io -c "write -P 0xa 0x200 0x400"), but
strtod() parses "08" as 8 rather than as an invalid octal number, so
we know there are no clients that depend on octal. Our use of
strtod() also means that "0x1.8k" would actually parse as 1536 (the
fraction is 8/16), rather than 1843 (if the fraction were 8/10); but
as this was not covered in the testsuite, I have no qualms forbidding
hex fractions as invalid, so this patch declares that the use of
fractions is only supported with decimal input, and enhances the
testsuite to document that.
Our previous use of strtod() meant that -1 parsed as a negative; now
that we parse with strtoull(), negative values can wrap around modulo
2^64, so we have to explicitly check whether the user passed in a '-';
and make it consistent to also reject '-0'. This has the minor effect
of treating negative values as EINVAL (with no change to endptr)
rather than ERANGE (with endptr advanced to what was parsed), visible
in the updated iotest output.
We also had no testsuite coverage of "1.1e0k", which happened to parse
under strtod() but is unlikely to occur in practice; as long as we are
making things more robust, it is easy enough to reject the use of
exponents in a strtod parse.
The fix is done by breaking the parse into an integer prefix (no loss
in precision), rejecting negative values (since we can no longer rely
on strtod() to do that), determining if a decimal or hexadecimal parse
was intended (with the new restriction that a fractional hex parse is
not allowed), and where appropriate, using a floating point fractional
parse (where we also scan to reject use of exponents in the fraction).
The bulk of the patch is then updates to the testsuite to match our
new precision, as well as adding new cases we reject (whether they
were rejected or inadvertently accepted before).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20210211204438.1184395-3-eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 23:44:36 +03:00
|
|
|
*
|
|
|
|
* The end pointer will be returned in *end, if not NULL. If there is
|
|
|
|
* no fraction, the input can be decimal or hexadecimal; if there is a
|
cutils: Set value in all qemu_strtosz* error paths
Making callers determine whether or not *value was populated on error
is not nice for usability. Pre-patch, we have unit tests that check
that *result is left unchanged on most EINVAL errors and set to 0 on
many ERANGE errors. This is subtly different from libc strtoumax()
behavior which returns UINT64_MAX on ERANGE errors, as well as
different from our parse_uint() which slams to 0 on EINVAL on the
grounds that we want our functions to be harder to mis-use than
strtoumax().
Let's audit callers:
- hw/core/numa.c:parse_numa() fixed in the previous patch to check for
errors
- migration/migration-hmp-cmds.c:hmp_migrate_set_parameter(),
monitor/hmp.c:monitor_parse_arguments(),
qapi/opts-visitor.c:opts_type_size(),
qapi/qobject-input-visitor.c:qobject_input_type_size_keyval(),
qemu-img.c:cvtnum_full(), qemu-io-cmds.c:cvtnum(),
target/i386/cpu.c:x86_cpu_parse_featurestr(), and
util/qemu-option.c:parse_option_size() appear to reject all failures
(although some with distinct messages for ERANGE as opposed to
EINVAL), so it doesn't matter what is in the value parameter on
error.
- All remaining callers are in the testsuite, where we can tweak our
expectations to match our new desired behavior.
Advancing to the end of the string parsed on overflow (ERANGE), while
still returning 0, makes sense (UINT64_MAX as a size is unlikely to be
useful); likewise, our size parsing code is complex enough that it's
easier to always return 0 when endptr is NULL but trailing garbage was
found, rather than trying to return the value of the prefix actually
parsed (no current caller cared about the value of the prefix).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Hanna Czenczek <hreitz@redhat.com>
Message-Id: <20230522190441.64278-16-eblake@redhat.com>
2023-05-22 22:04:37 +03:00
|
|
|
* non-zero fraction, then the input must be decimal and there must be
|
|
|
|
* a suffix (possibly by @default_suffix) larger than Byte, and the
|
|
|
|
* fractional portion may suffer from precision loss or rounding. The
|
|
|
|
* input must be positive.
|
utils: Improve qemu_strtosz() to have 64 bits of precision
We have multiple clients of qemu_strtosz (qemu-io, the opts visitor,
the keyval visitor), and it gets annoying that edge-case testing is
impacted by implicit rounding to 53 bits of precision due to parsing
with strtod(). As an example posted by Rich Jones:
$ nbdkit memory $(( 2**63 - 2**30 )) --run \
'build/qemu-io -f raw "$uri" -c "w -P 3 $(( 2**63 - 2**30 - 512 )) 512" '
write failed: Input/output error
because 9223372035781033472 got rounded to 0x7fffffffc0000000 which is
out of bounds.
It is also worth noting that our existing parser, by virtue of using
strtod(), accepts decimal AND hex numbers, even though test-cutils
previously lacked any coverage of the latter until the previous patch.
We do have existing clients that expect a hex parse to work (for
example, iotest 33 using qemu-io -c "write -P 0xa 0x200 0x400"), but
strtod() parses "08" as 8 rather than as an invalid octal number, so
we know there are no clients that depend on octal. Our use of
strtod() also means that "0x1.8k" would actually parse as 1536 (the
fraction is 8/16), rather than 1843 (if the fraction were 8/10); but
as this was not covered in the testsuite, I have no qualms forbidding
hex fractions as invalid, so this patch declares that the use of
fractions is only supported with decimal input, and enhances the
testsuite to document that.
Our previous use of strtod() meant that -1 parsed as a negative; now
that we parse with strtoull(), negative values can wrap around modulo
2^64, so we have to explicitly check whether the user passed in a '-';
and make it consistent to also reject '-0'. This has the minor effect
of treating negative values as EINVAL (with no change to endptr)
rather than ERANGE (with endptr advanced to what was parsed), visible
in the updated iotest output.
We also had no testsuite coverage of "1.1e0k", which happened to parse
under strtod() but is unlikely to occur in practice; as long as we are
making things more robust, it is easy enough to reject the use of
exponents in a strtod parse.
The fix is done by breaking the parse into an integer prefix (no loss
in precision), rejecting negative values (since we can no longer rely
on strtod() to do that), determining if a decimal or hexadecimal parse
was intended (with the new restriction that a fractional hex parse is
not allowed), and where appropriate, using a floating point fractional
parse (where we also scan to reject use of exponents in the fraction).
The bulk of the patch is then updates to the testsuite to match our
new precision, as well as adding new cases we reject (whether they
were rejected or inadvertently accepted before).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20210211204438.1184395-3-eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 23:44:36 +03:00
|
|
|
*
|
|
|
|
* Return -ERANGE on overflow (with *@end advanced), and -EINVAL on
|
cutils: Set value in all qemu_strtosz* error paths
Making callers determine whether or not *value was populated on error
is not nice for usability. Pre-patch, we have unit tests that check
that *result is left unchanged on most EINVAL errors and set to 0 on
many ERANGE errors. This is subtly different from libc strtoumax()
behavior which returns UINT64_MAX on ERANGE errors, as well as
different from our parse_uint() which slams to 0 on EINVAL on the
grounds that we want our functions to be harder to mis-use than
strtoumax().
Let's audit callers:
- hw/core/numa.c:parse_numa() fixed in the previous patch to check for
errors
- migration/migration-hmp-cmds.c:hmp_migrate_set_parameter(),
monitor/hmp.c:monitor_parse_arguments(),
qapi/opts-visitor.c:opts_type_size(),
qapi/qobject-input-visitor.c:qobject_input_type_size_keyval(),
qemu-img.c:cvtnum_full(), qemu-io-cmds.c:cvtnum(),
target/i386/cpu.c:x86_cpu_parse_featurestr(), and
util/qemu-option.c:parse_option_size() appear to reject all failures
(although some with distinct messages for ERANGE as opposed to
EINVAL), so it doesn't matter what is in the value parameter on
error.
- All remaining callers are in the testsuite, where we can tweak our
expectations to match our new desired behavior.
Advancing to the end of the string parsed on overflow (ERANGE), while
still returning 0, makes sense (UINT64_MAX as a size is unlikely to be
useful); likewise, our size parsing code is complex enough that it's
easier to always return 0 when endptr is NULL but trailing garbage was
found, rather than trying to return the value of the prefix actually
parsed (no current caller cared about the value of the prefix).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Hanna Czenczek <hreitz@redhat.com>
Message-Id: <20230522190441.64278-16-eblake@redhat.com>
2023-05-22 22:04:37 +03:00
|
|
|
* other error (with *@end at @nptr). Unlike strtoull, *@result is
|
|
|
|
* set to 0 on all errors, as returning UINT64_MAX on overflow is less
|
|
|
|
* likely to be usable as a size.
|
2010-10-21 19:15:46 +04:00
|
|
|
*/
|
2018-11-21 19:44:14 +03:00
|
|
|
static int do_strtosz(const char *nptr, const char **end,
|
2017-02-21 23:14:06 +03:00
|
|
|
const char default_suffix, int64_t unit,
|
2017-02-21 23:14:07 +03:00
|
|
|
uint64_t *result)
|
2010-10-21 19:15:46 +04:00
|
|
|
{
|
2017-02-21 23:14:06 +03:00
|
|
|
int retval;
|
2023-05-22 22:04:41 +03:00
|
|
|
const char *endptr;
|
cutils: Make strtosz & friends leave follow set to callers
strtosz() & friends require the size to be at the end of the string,
or be followed by whitespace or ','. I find this surprising, because
the name suggests it works like strtol().
The check simplifies callers that accept exactly that follow set
slightly. No such callers exist.
The check is redundant for callers that accept a smaller follow set,
and thus need to check themselves anyway. Right now, this is the case
for all but one caller. All of them neglected to check, or checked
incorrectly, but the previous few commits fixed them up.
Finally, the check is problematic for callers that accept a larger
follow set. This is the case in monitor_parse_command().
Fortunately, the problems there are relatively harmless.
monitor_parse_command() uses strtosz() for argument type 'o'. When
the last argument is of type 'o', a trailing ',' is diagnosed
differently than other trailing junk:
(qemu) migrate_set_speed 1x
invalid size
(qemu) migrate_set_speed 1,
migrate_set_speed: extraneous characters at the end of line
A related inconsistency exists with non-last arguments. No such
command exists, but let's use memsave to explore the inconsistency.
The monitor permits, but does not require whitespace between
arguments. For instance, "memsave (1-1)1024foo" is parsed as command
memsave with three arguments 0, 1024 and "foo". Yes, this is daft,
but at least it's consistently daft.
If I change memsave's second argument from 'i' to 'o', then "memsave
(1-1)1foo" is rejected, because the size is followed by an 'f'. But
"memsave (1-1)1," is still accepted, and duly saves to file ",".
We don't have any users of strtosz that profit from the check. In the
users we have, it appears to encourage sloppy error checking, or gets
in the way. Drop the bothersome check.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-11-22 12:46:06 +04:00
|
|
|
unsigned char c;
|
2023-05-22 22:04:41 +03:00
|
|
|
uint64_t val = 0, valf = 0;
|
utils: Improve qemu_strtosz() to have 64 bits of precision
We have multiple clients of qemu_strtosz (qemu-io, the opts visitor,
the keyval visitor), and it gets annoying that edge-case testing is
impacted by implicit rounding to 53 bits of precision due to parsing
with strtod(). As an example posted by Rich Jones:
$ nbdkit memory $(( 2**63 - 2**30 )) --run \
'build/qemu-io -f raw "$uri" -c "w -P 3 $(( 2**63 - 2**30 - 512 )) 512" '
write failed: Input/output error
because 9223372035781033472 got rounded to 0x7fffffffc0000000 which is
out of bounds.
It is also worth noting that our existing parser, by virtue of using
strtod(), accepts decimal AND hex numbers, even though test-cutils
previously lacked any coverage of the latter until the previous patch.
We do have existing clients that expect a hex parse to work (for
example, iotest 33 using qemu-io -c "write -P 0xa 0x200 0x400"), but
strtod() parses "08" as 8 rather than as an invalid octal number, so
we know there are no clients that depend on octal. Our use of
strtod() also means that "0x1.8k" would actually parse as 1536 (the
fraction is 8/16), rather than 1843 (if the fraction were 8/10); but
as this was not covered in the testsuite, I have no qualms forbidding
hex fractions as invalid, so this patch declares that the use of
fractions is only supported with decimal input, and enhances the
testsuite to document that.
Our previous use of strtod() meant that -1 parsed as a negative; now
that we parse with strtoull(), negative values can wrap around modulo
2^64, so we have to explicitly check whether the user passed in a '-';
and make it consistent to also reject '-0'. This has the minor effect
of treating negative values as EINVAL (with no change to endptr)
rather than ERANGE (with endptr advanced to what was parsed), visible
in the updated iotest output.
We also had no testsuite coverage of "1.1e0k", which happened to parse
under strtod() but is unlikely to occur in practice; as long as we are
making things more robust, it is easy enough to reject the use of
exponents in a strtod parse.
The fix is done by breaking the parse into an integer prefix (no loss
in precision), rejecting negative values (since we can no longer rely
on strtod() to do that), determining if a decimal or hexadecimal parse
was intended (with the new restriction that a fractional hex parse is
not allowed), and where appropriate, using a floating point fractional
parse (where we also scan to reject use of exponents in the fraction).
The bulk of the patch is then updates to the testsuite to match our
new precision, as well as adding new cases we reject (whether they
were rejected or inadvertently accepted before).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20210211204438.1184395-3-eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 23:44:36 +03:00
|
|
|
int64_t mul;
|
2010-10-21 19:15:46 +04:00
|
|
|
|
utils: Improve qemu_strtosz() to have 64 bits of precision
We have multiple clients of qemu_strtosz (qemu-io, the opts visitor,
the keyval visitor), and it gets annoying that edge-case testing is
impacted by implicit rounding to 53 bits of precision due to parsing
with strtod(). As an example posted by Rich Jones:
$ nbdkit memory $(( 2**63 - 2**30 )) --run \
'build/qemu-io -f raw "$uri" -c "w -P 3 $(( 2**63 - 2**30 - 512 )) 512" '
write failed: Input/output error
because 9223372035781033472 got rounded to 0x7fffffffc0000000 which is
out of bounds.
It is also worth noting that our existing parser, by virtue of using
strtod(), accepts decimal AND hex numbers, even though test-cutils
previously lacked any coverage of the latter until the previous patch.
We do have existing clients that expect a hex parse to work (for
example, iotest 33 using qemu-io -c "write -P 0xa 0x200 0x400"), but
strtod() parses "08" as 8 rather than as an invalid octal number, so
we know there are no clients that depend on octal. Our use of
strtod() also means that "0x1.8k" would actually parse as 1536 (the
fraction is 8/16), rather than 1843 (if the fraction were 8/10); but
as this was not covered in the testsuite, I have no qualms forbidding
hex fractions as invalid, so this patch declares that the use of
fractions is only supported with decimal input, and enhances the
testsuite to document that.
Our previous use of strtod() meant that -1 parsed as a negative; now
that we parse with strtoull(), negative values can wrap around modulo
2^64, so we have to explicitly check whether the user passed in a '-';
and make it consistent to also reject '-0'. This has the minor effect
of treating negative values as EINVAL (with no change to endptr)
rather than ERANGE (with endptr advanced to what was parsed), visible
in the updated iotest output.
We also had no testsuite coverage of "1.1e0k", which happened to parse
under strtod() but is unlikely to occur in practice; as long as we are
making things more robust, it is easy enough to reject the use of
exponents in a strtod parse.
The fix is done by breaking the parse into an integer prefix (no loss
in precision), rejecting negative values (since we can no longer rely
on strtod() to do that), determining if a decimal or hexadecimal parse
was intended (with the new restriction that a fractional hex parse is
not allowed), and where appropriate, using a floating point fractional
parse (where we also scan to reject use of exponents in the fraction).
The bulk of the patch is then updates to the testsuite to match our
new precision, as well as adding new cases we reject (whether they
were rejected or inadvertently accepted before).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20210211204438.1184395-3-eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 23:44:36 +03:00
|
|
|
/* Parse integral portion as decimal. */
|
2023-05-22 22:04:39 +03:00
|
|
|
retval = parse_uint(nptr, &endptr, 10, &val);
|
2023-05-22 22:04:41 +03:00
|
|
|
if (retval == -ERANGE || !nptr) {
|
2017-02-21 23:14:05 +03:00
|
|
|
goto out;
|
2010-10-21 19:15:46 +04:00
|
|
|
}
|
2023-05-22 22:04:41 +03:00
|
|
|
if (retval == 0 && val == 0 && (*endptr == 'x' || *endptr == 'X')) {
|
2022-12-16 12:50:05 +03:00
|
|
|
/* Input looks like hex; reparse, and insist on no fraction or suffix. */
|
utils: Improve qemu_strtosz() to have 64 bits of precision
We have multiple clients of qemu_strtosz (qemu-io, the opts visitor,
the keyval visitor), and it gets annoying that edge-case testing is
impacted by implicit rounding to 53 bits of precision due to parsing
with strtod(). As an example posted by Rich Jones:
$ nbdkit memory $(( 2**63 - 2**30 )) --run \
'build/qemu-io -f raw "$uri" -c "w -P 3 $(( 2**63 - 2**30 - 512 )) 512" '
write failed: Input/output error
because 9223372035781033472 got rounded to 0x7fffffffc0000000 which is
out of bounds.
It is also worth noting that our existing parser, by virtue of using
strtod(), accepts decimal AND hex numbers, even though test-cutils
previously lacked any coverage of the latter until the previous patch.
We do have existing clients that expect a hex parse to work (for
example, iotest 33 using qemu-io -c "write -P 0xa 0x200 0x400"), but
strtod() parses "08" as 8 rather than as an invalid octal number, so
we know there are no clients that depend on octal. Our use of
strtod() also means that "0x1.8k" would actually parse as 1536 (the
fraction is 8/16), rather than 1843 (if the fraction were 8/10); but
as this was not covered in the testsuite, I have no qualms forbidding
hex fractions as invalid, so this patch declares that the use of
fractions is only supported with decimal input, and enhances the
testsuite to document that.
Our previous use of strtod() meant that -1 parsed as a negative; now
that we parse with strtoull(), negative values can wrap around modulo
2^64, so we have to explicitly check whether the user passed in a '-';
and make it consistent to also reject '-0'. This has the minor effect
of treating negative values as EINVAL (with no change to endptr)
rather than ERANGE (with endptr advanced to what was parsed), visible
in the updated iotest output.
We also had no testsuite coverage of "1.1e0k", which happened to parse
under strtod() but is unlikely to occur in practice; as long as we are
making things more robust, it is easy enough to reject the use of
exponents in a strtod parse.
The fix is done by breaking the parse into an integer prefix (no loss
in precision), rejecting negative values (since we can no longer rely
on strtod() to do that), determining if a decimal or hexadecimal parse
was intended (with the new restriction that a fractional hex parse is
not allowed), and where appropriate, using a floating point fractional
parse (where we also scan to reject use of exponents in the fraction).
The bulk of the patch is then updates to the testsuite to match our
new precision, as well as adding new cases we reject (whether they
were rejected or inadvertently accepted before).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20210211204438.1184395-3-eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 23:44:36 +03:00
|
|
|
retval = qemu_strtou64(nptr, &endptr, 16, &val);
|
|
|
|
if (retval) {
|
|
|
|
goto out;
|
|
|
|
}
|
2022-12-16 12:50:05 +03:00
|
|
|
if (*endptr == '.' || suffix_mul(*endptr, unit) > 0) {
|
utils: Improve qemu_strtosz() to have 64 bits of precision
We have multiple clients of qemu_strtosz (qemu-io, the opts visitor,
the keyval visitor), and it gets annoying that edge-case testing is
impacted by implicit rounding to 53 bits of precision due to parsing
with strtod(). As an example posted by Rich Jones:
$ nbdkit memory $(( 2**63 - 2**30 )) --run \
'build/qemu-io -f raw "$uri" -c "w -P 3 $(( 2**63 - 2**30 - 512 )) 512" '
write failed: Input/output error
because 9223372035781033472 got rounded to 0x7fffffffc0000000 which is
out of bounds.
It is also worth noting that our existing parser, by virtue of using
strtod(), accepts decimal AND hex numbers, even though test-cutils
previously lacked any coverage of the latter until the previous patch.
We do have existing clients that expect a hex parse to work (for
example, iotest 33 using qemu-io -c "write -P 0xa 0x200 0x400"), but
strtod() parses "08" as 8 rather than as an invalid octal number, so
we know there are no clients that depend on octal. Our use of
strtod() also means that "0x1.8k" would actually parse as 1536 (the
fraction is 8/16), rather than 1843 (if the fraction were 8/10); but
as this was not covered in the testsuite, I have no qualms forbidding
hex fractions as invalid, so this patch declares that the use of
fractions is only supported with decimal input, and enhances the
testsuite to document that.
Our previous use of strtod() meant that -1 parsed as a negative; now
that we parse with strtoull(), negative values can wrap around modulo
2^64, so we have to explicitly check whether the user passed in a '-';
and make it consistent to also reject '-0'. This has the minor effect
of treating negative values as EINVAL (with no change to endptr)
rather than ERANGE (with endptr advanced to what was parsed), visible
in the updated iotest output.
We also had no testsuite coverage of "1.1e0k", which happened to parse
under strtod() but is unlikely to occur in practice; as long as we are
making things more robust, it is easy enough to reject the use of
exponents in a strtod parse.
The fix is done by breaking the parse into an integer prefix (no loss
in precision), rejecting negative values (since we can no longer rely
on strtod() to do that), determining if a decimal or hexadecimal parse
was intended (with the new restriction that a fractional hex parse is
not allowed), and where appropriate, using a floating point fractional
parse (where we also scan to reject use of exponents in the fraction).
The bulk of the patch is then updates to the testsuite to match our
new precision, as well as adding new cases we reject (whether they
were rejected or inadvertently accepted before).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20210211204438.1184395-3-eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 23:44:36 +03:00
|
|
|
endptr = nptr;
|
|
|
|
retval = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
2023-05-22 22:04:41 +03:00
|
|
|
} else if (*endptr == '.' || (endptr == nptr && strchr(nptr, '.'))) {
|
utils: Improve qemu_strtosz() to have 64 bits of precision
We have multiple clients of qemu_strtosz (qemu-io, the opts visitor,
the keyval visitor), and it gets annoying that edge-case testing is
impacted by implicit rounding to 53 bits of precision due to parsing
with strtod(). As an example posted by Rich Jones:
$ nbdkit memory $(( 2**63 - 2**30 )) --run \
'build/qemu-io -f raw "$uri" -c "w -P 3 $(( 2**63 - 2**30 - 512 )) 512" '
write failed: Input/output error
because 9223372035781033472 got rounded to 0x7fffffffc0000000 which is
out of bounds.
It is also worth noting that our existing parser, by virtue of using
strtod(), accepts decimal AND hex numbers, even though test-cutils
previously lacked any coverage of the latter until the previous patch.
We do have existing clients that expect a hex parse to work (for
example, iotest 33 using qemu-io -c "write -P 0xa 0x200 0x400"), but
strtod() parses "08" as 8 rather than as an invalid octal number, so
we know there are no clients that depend on octal. Our use of
strtod() also means that "0x1.8k" would actually parse as 1536 (the
fraction is 8/16), rather than 1843 (if the fraction were 8/10); but
as this was not covered in the testsuite, I have no qualms forbidding
hex fractions as invalid, so this patch declares that the use of
fractions is only supported with decimal input, and enhances the
testsuite to document that.
Our previous use of strtod() meant that -1 parsed as a negative; now
that we parse with strtoull(), negative values can wrap around modulo
2^64, so we have to explicitly check whether the user passed in a '-';
and make it consistent to also reject '-0'. This has the minor effect
of treating negative values as EINVAL (with no change to endptr)
rather than ERANGE (with endptr advanced to what was parsed), visible
in the updated iotest output.
We also had no testsuite coverage of "1.1e0k", which happened to parse
under strtod() but is unlikely to occur in practice; as long as we are
making things more robust, it is easy enough to reject the use of
exponents in a strtod parse.
The fix is done by breaking the parse into an integer prefix (no loss
in precision), rejecting negative values (since we can no longer rely
on strtod() to do that), determining if a decimal or hexadecimal parse
was intended (with the new restriction that a fractional hex parse is
not allowed), and where appropriate, using a floating point fractional
parse (where we also scan to reject use of exponents in the fraction).
The bulk of the patch is then updates to the testsuite to match our
new precision, as well as adding new cases we reject (whether they
were rejected or inadvertently accepted before).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20210211204438.1184395-3-eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 23:44:36 +03:00
|
|
|
/*
|
|
|
|
* Input looks like a fraction. Make sure even 1.k works
|
2023-05-22 22:04:41 +03:00
|
|
|
* without fractional digits. strtod tries to treat 'e' as an
|
|
|
|
* exponent, but we want to treat it as a scaling suffix;
|
|
|
|
* doing this requires modifying a copy of the fraction.
|
utils: Improve qemu_strtosz() to have 64 bits of precision
We have multiple clients of qemu_strtosz (qemu-io, the opts visitor,
the keyval visitor), and it gets annoying that edge-case testing is
impacted by implicit rounding to 53 bits of precision due to parsing
with strtod(). As an example posted by Rich Jones:
$ nbdkit memory $(( 2**63 - 2**30 )) --run \
'build/qemu-io -f raw "$uri" -c "w -P 3 $(( 2**63 - 2**30 - 512 )) 512" '
write failed: Input/output error
because 9223372035781033472 got rounded to 0x7fffffffc0000000 which is
out of bounds.
It is also worth noting that our existing parser, by virtue of using
strtod(), accepts decimal AND hex numbers, even though test-cutils
previously lacked any coverage of the latter until the previous patch.
We do have existing clients that expect a hex parse to work (for
example, iotest 33 using qemu-io -c "write -P 0xa 0x200 0x400"), but
strtod() parses "08" as 8 rather than as an invalid octal number, so
we know there are no clients that depend on octal. Our use of
strtod() also means that "0x1.8k" would actually parse as 1536 (the
fraction is 8/16), rather than 1843 (if the fraction were 8/10); but
as this was not covered in the testsuite, I have no qualms forbidding
hex fractions as invalid, so this patch declares that the use of
fractions is only supported with decimal input, and enhances the
testsuite to document that.
Our previous use of strtod() meant that -1 parsed as a negative; now
that we parse with strtoull(), negative values can wrap around modulo
2^64, so we have to explicitly check whether the user passed in a '-';
and make it consistent to also reject '-0'. This has the minor effect
of treating negative values as EINVAL (with no change to endptr)
rather than ERANGE (with endptr advanced to what was parsed), visible
in the updated iotest output.
We also had no testsuite coverage of "1.1e0k", which happened to parse
under strtod() but is unlikely to occur in practice; as long as we are
making things more robust, it is easy enough to reject the use of
exponents in a strtod parse.
The fix is done by breaking the parse into an integer prefix (no loss
in precision), rejecting negative values (since we can no longer rely
on strtod() to do that), determining if a decimal or hexadecimal parse
was intended (with the new restriction that a fractional hex parse is
not allowed), and where appropriate, using a floating point fractional
parse (where we also scan to reject use of exponents in the fraction).
The bulk of the patch is then updates to the testsuite to match our
new precision, as well as adding new cases we reject (whether they
were rejected or inadvertently accepted before).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20210211204438.1184395-3-eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 23:44:36 +03:00
|
|
|
*/
|
2023-05-22 22:04:41 +03:00
|
|
|
double fraction = 0.0;
|
2021-03-15 01:49:30 +03:00
|
|
|
|
2023-05-22 22:04:41 +03:00
|
|
|
if (retval == 0 && *endptr == '.' && !isdigit(endptr[1])) {
|
|
|
|
/* If we got here, we parsed at least one digit already. */
|
utils: Improve qemu_strtosz() to have 64 bits of precision
We have multiple clients of qemu_strtosz (qemu-io, the opts visitor,
the keyval visitor), and it gets annoying that edge-case testing is
impacted by implicit rounding to 53 bits of precision due to parsing
with strtod(). As an example posted by Rich Jones:
$ nbdkit memory $(( 2**63 - 2**30 )) --run \
'build/qemu-io -f raw "$uri" -c "w -P 3 $(( 2**63 - 2**30 - 512 )) 512" '
write failed: Input/output error
because 9223372035781033472 got rounded to 0x7fffffffc0000000 which is
out of bounds.
It is also worth noting that our existing parser, by virtue of using
strtod(), accepts decimal AND hex numbers, even though test-cutils
previously lacked any coverage of the latter until the previous patch.
We do have existing clients that expect a hex parse to work (for
example, iotest 33 using qemu-io -c "write -P 0xa 0x200 0x400"), but
strtod() parses "08" as 8 rather than as an invalid octal number, so
we know there are no clients that depend on octal. Our use of
strtod() also means that "0x1.8k" would actually parse as 1536 (the
fraction is 8/16), rather than 1843 (if the fraction were 8/10); but
as this was not covered in the testsuite, I have no qualms forbidding
hex fractions as invalid, so this patch declares that the use of
fractions is only supported with decimal input, and enhances the
testsuite to document that.
Our previous use of strtod() meant that -1 parsed as a negative; now
that we parse with strtoull(), negative values can wrap around modulo
2^64, so we have to explicitly check whether the user passed in a '-';
and make it consistent to also reject '-0'. This has the minor effect
of treating negative values as EINVAL (with no change to endptr)
rather than ERANGE (with endptr advanced to what was parsed), visible
in the updated iotest output.
We also had no testsuite coverage of "1.1e0k", which happened to parse
under strtod() but is unlikely to occur in practice; as long as we are
making things more robust, it is easy enough to reject the use of
exponents in a strtod parse.
The fix is done by breaking the parse into an integer prefix (no loss
in precision), rejecting negative values (since we can no longer rely
on strtod() to do that), determining if a decimal or hexadecimal parse
was intended (with the new restriction that a fractional hex parse is
not allowed), and where appropriate, using a floating point fractional
parse (where we also scan to reject use of exponents in the fraction).
The bulk of the patch is then updates to the testsuite to match our
new precision, as well as adding new cases we reject (whether they
were rejected or inadvertently accepted before).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20210211204438.1184395-3-eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 23:44:36 +03:00
|
|
|
endptr++;
|
2021-03-15 01:49:30 +03:00
|
|
|
} else {
|
2023-05-22 22:04:41 +03:00
|
|
|
char *e;
|
|
|
|
const char *tail;
|
|
|
|
g_autofree char *copy = g_strdup(endptr);
|
|
|
|
|
|
|
|
e = strchr(copy, 'e');
|
|
|
|
if (e) {
|
|
|
|
*e = '\0';
|
|
|
|
}
|
|
|
|
e = strchr(copy, 'E');
|
|
|
|
if (e) {
|
|
|
|
*e = '\0';
|
|
|
|
}
|
|
|
|
/*
|
|
|
|
* If this is a floating point, we are guaranteed that '.'
|
|
|
|
* appears before any possible digits in copy. If it is
|
|
|
|
* not a floating point, strtod will fail. Either way,
|
|
|
|
* there is now no exponent in copy, so if it parses, we
|
|
|
|
* know 0.0 <= abs(result) <= 1.0 (after rounding), and
|
|
|
|
* ERANGE is only possible on underflow which is okay.
|
|
|
|
*/
|
|
|
|
retval = qemu_strtod_finite(copy, &tail, &fraction);
|
|
|
|
endptr += tail - copy;
|
|
|
|
if (signbit(fraction)) {
|
|
|
|
retval = -ERANGE;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Extract into a 64-bit fixed-point fraction. */
|
|
|
|
if (fraction == 1.0) {
|
|
|
|
if (val == UINT64_MAX) {
|
|
|
|
retval = -ERANGE;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
val++;
|
|
|
|
} else if (retval == -ERANGE) {
|
|
|
|
/* See comments above about underflow */
|
|
|
|
valf = 1;
|
|
|
|
retval = 0;
|
|
|
|
} else {
|
|
|
|
/* We want non-zero valf for any non-zero fraction */
|
2021-03-15 01:49:30 +03:00
|
|
|
valf = (uint64_t)(fraction * 0x1p64);
|
2023-05-22 22:04:41 +03:00
|
|
|
if (valf == 0 && fraction > 0.0) {
|
|
|
|
valf = 1;
|
|
|
|
}
|
utils: Improve qemu_strtosz() to have 64 bits of precision
We have multiple clients of qemu_strtosz (qemu-io, the opts visitor,
the keyval visitor), and it gets annoying that edge-case testing is
impacted by implicit rounding to 53 bits of precision due to parsing
with strtod(). As an example posted by Rich Jones:
$ nbdkit memory $(( 2**63 - 2**30 )) --run \
'build/qemu-io -f raw "$uri" -c "w -P 3 $(( 2**63 - 2**30 - 512 )) 512" '
write failed: Input/output error
because 9223372035781033472 got rounded to 0x7fffffffc0000000 which is
out of bounds.
It is also worth noting that our existing parser, by virtue of using
strtod(), accepts decimal AND hex numbers, even though test-cutils
previously lacked any coverage of the latter until the previous patch.
We do have existing clients that expect a hex parse to work (for
example, iotest 33 using qemu-io -c "write -P 0xa 0x200 0x400"), but
strtod() parses "08" as 8 rather than as an invalid octal number, so
we know there are no clients that depend on octal. Our use of
strtod() also means that "0x1.8k" would actually parse as 1536 (the
fraction is 8/16), rather than 1843 (if the fraction were 8/10); but
as this was not covered in the testsuite, I have no qualms forbidding
hex fractions as invalid, so this patch declares that the use of
fractions is only supported with decimal input, and enhances the
testsuite to document that.
Our previous use of strtod() meant that -1 parsed as a negative; now
that we parse with strtoull(), negative values can wrap around modulo
2^64, so we have to explicitly check whether the user passed in a '-';
and make it consistent to also reject '-0'. This has the minor effect
of treating negative values as EINVAL (with no change to endptr)
rather than ERANGE (with endptr advanced to what was parsed), visible
in the updated iotest output.
We also had no testsuite coverage of "1.1e0k", which happened to parse
under strtod() but is unlikely to occur in practice; as long as we are
making things more robust, it is easy enough to reject the use of
exponents in a strtod parse.
The fix is done by breaking the parse into an integer prefix (no loss
in precision), rejecting negative values (since we can no longer rely
on strtod() to do that), determining if a decimal or hexadecimal parse
was intended (with the new restriction that a fractional hex parse is
not allowed), and where appropriate, using a floating point fractional
parse (where we also scan to reject use of exponents in the fraction).
The bulk of the patch is then updates to the testsuite to match our
new precision, as well as adding new cases we reject (whether they
were rejected or inadvertently accepted before).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20210211204438.1184395-3-eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 23:44:36 +03:00
|
|
|
}
|
2010-10-21 19:15:46 +04:00
|
|
|
}
|
2023-05-22 22:04:41 +03:00
|
|
|
if (retval) {
|
|
|
|
goto out;
|
|
|
|
}
|
2010-10-21 19:15:46 +04:00
|
|
|
c = *endptr;
|
cutils: Make strtosz & friends leave follow set to callers
strtosz() & friends require the size to be at the end of the string,
or be followed by whitespace or ','. I find this surprising, because
the name suggests it works like strtol().
The check simplifies callers that accept exactly that follow set
slightly. No such callers exist.
The check is redundant for callers that accept a smaller follow set,
and thus need to check themselves anyway. Right now, this is the case
for all but one caller. All of them neglected to check, or checked
incorrectly, but the previous few commits fixed them up.
Finally, the check is problematic for callers that accept a larger
follow set. This is the case in monitor_parse_command().
Fortunately, the problems there are relatively harmless.
monitor_parse_command() uses strtosz() for argument type 'o'. When
the last argument is of type 'o', a trailing ',' is diagnosed
differently than other trailing junk:
(qemu) migrate_set_speed 1x
invalid size
(qemu) migrate_set_speed 1,
migrate_set_speed: extraneous characters at the end of line
A related inconsistency exists with non-last arguments. No such
command exists, but let's use memsave to explore the inconsistency.
The monitor permits, but does not require whitespace between
arguments. For instance, "memsave (1-1)1024foo" is parsed as command
memsave with three arguments 0, 1024 and "foo". Yes, this is daft,
but at least it's consistently daft.
If I change memsave's second argument from 'i' to 'o', then "memsave
(1-1)1foo" is rejected, because the size is followed by an 'f'. But
"memsave (1-1)1," is still accepted, and duly saves to file ",".
We don't have any users of strtosz that profit from the check. In the
users we have, it appears to encourage sloppy error checking, or gets
in the way. Drop the bothersome check.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-11-22 12:46:06 +04:00
|
|
|
mul = suffix_mul(c, unit);
|
utils: Improve qemu_strtosz() to have 64 bits of precision
We have multiple clients of qemu_strtosz (qemu-io, the opts visitor,
the keyval visitor), and it gets annoying that edge-case testing is
impacted by implicit rounding to 53 bits of precision due to parsing
with strtod(). As an example posted by Rich Jones:
$ nbdkit memory $(( 2**63 - 2**30 )) --run \
'build/qemu-io -f raw "$uri" -c "w -P 3 $(( 2**63 - 2**30 - 512 )) 512" '
write failed: Input/output error
because 9223372035781033472 got rounded to 0x7fffffffc0000000 which is
out of bounds.
It is also worth noting that our existing parser, by virtue of using
strtod(), accepts decimal AND hex numbers, even though test-cutils
previously lacked any coverage of the latter until the previous patch.
We do have existing clients that expect a hex parse to work (for
example, iotest 33 using qemu-io -c "write -P 0xa 0x200 0x400"), but
strtod() parses "08" as 8 rather than as an invalid octal number, so
we know there are no clients that depend on octal. Our use of
strtod() also means that "0x1.8k" would actually parse as 1536 (the
fraction is 8/16), rather than 1843 (if the fraction were 8/10); but
as this was not covered in the testsuite, I have no qualms forbidding
hex fractions as invalid, so this patch declares that the use of
fractions is only supported with decimal input, and enhances the
testsuite to document that.
Our previous use of strtod() meant that -1 parsed as a negative; now
that we parse with strtoull(), negative values can wrap around modulo
2^64, so we have to explicitly check whether the user passed in a '-';
and make it consistent to also reject '-0'. This has the minor effect
of treating negative values as EINVAL (with no change to endptr)
rather than ERANGE (with endptr advanced to what was parsed), visible
in the updated iotest output.
We also had no testsuite coverage of "1.1e0k", which happened to parse
under strtod() but is unlikely to occur in practice; as long as we are
making things more robust, it is easy enough to reject the use of
exponents in a strtod parse.
The fix is done by breaking the parse into an integer prefix (no loss
in precision), rejecting negative values (since we can no longer rely
on strtod() to do that), determining if a decimal or hexadecimal parse
was intended (with the new restriction that a fractional hex parse is
not allowed), and where appropriate, using a floating point fractional
parse (where we also scan to reject use of exponents in the fraction).
The bulk of the patch is then updates to the testsuite to match our
new precision, as well as adding new cases we reject (whether they
were rejected or inadvertently accepted before).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20210211204438.1184395-3-eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 23:44:36 +03:00
|
|
|
if (mul > 0) {
|
cutils: Make strtosz & friends leave follow set to callers
strtosz() & friends require the size to be at the end of the string,
or be followed by whitespace or ','. I find this surprising, because
the name suggests it works like strtol().
The check simplifies callers that accept exactly that follow set
slightly. No such callers exist.
The check is redundant for callers that accept a smaller follow set,
and thus need to check themselves anyway. Right now, this is the case
for all but one caller. All of them neglected to check, or checked
incorrectly, but the previous few commits fixed them up.
Finally, the check is problematic for callers that accept a larger
follow set. This is the case in monitor_parse_command().
Fortunately, the problems there are relatively harmless.
monitor_parse_command() uses strtosz() for argument type 'o'. When
the last argument is of type 'o', a trailing ',' is diagnosed
differently than other trailing junk:
(qemu) migrate_set_speed 1x
invalid size
(qemu) migrate_set_speed 1,
migrate_set_speed: extraneous characters at the end of line
A related inconsistency exists with non-last arguments. No such
command exists, but let's use memsave to explore the inconsistency.
The monitor permits, but does not require whitespace between
arguments. For instance, "memsave (1-1)1024foo" is parsed as command
memsave with three arguments 0, 1024 and "foo". Yes, this is daft,
but at least it's consistently daft.
If I change memsave's second argument from 'i' to 'o', then "memsave
(1-1)1foo" is rejected, because the size is followed by an 'f'. But
"memsave (1-1)1," is still accepted, and duly saves to file ",".
We don't have any users of strtosz that profit from the check. In the
users we have, it appears to encourage sloppy error checking, or gets
in the way. Drop the bothersome check.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2011-11-22 12:46:06 +04:00
|
|
|
endptr++;
|
|
|
|
} else {
|
|
|
|
mul = suffix_mul(default_suffix, unit);
|
utils: Improve qemu_strtosz() to have 64 bits of precision
We have multiple clients of qemu_strtosz (qemu-io, the opts visitor,
the keyval visitor), and it gets annoying that edge-case testing is
impacted by implicit rounding to 53 bits of precision due to parsing
with strtod(). As an example posted by Rich Jones:
$ nbdkit memory $(( 2**63 - 2**30 )) --run \
'build/qemu-io -f raw "$uri" -c "w -P 3 $(( 2**63 - 2**30 - 512 )) 512" '
write failed: Input/output error
because 9223372035781033472 got rounded to 0x7fffffffc0000000 which is
out of bounds.
It is also worth noting that our existing parser, by virtue of using
strtod(), accepts decimal AND hex numbers, even though test-cutils
previously lacked any coverage of the latter until the previous patch.
We do have existing clients that expect a hex parse to work (for
example, iotest 33 using qemu-io -c "write -P 0xa 0x200 0x400"), but
strtod() parses "08" as 8 rather than as an invalid octal number, so
we know there are no clients that depend on octal. Our use of
strtod() also means that "0x1.8k" would actually parse as 1536 (the
fraction is 8/16), rather than 1843 (if the fraction were 8/10); but
as this was not covered in the testsuite, I have no qualms forbidding
hex fractions as invalid, so this patch declares that the use of
fractions is only supported with decimal input, and enhances the
testsuite to document that.
Our previous use of strtod() meant that -1 parsed as a negative; now
that we parse with strtoull(), negative values can wrap around modulo
2^64, so we have to explicitly check whether the user passed in a '-';
and make it consistent to also reject '-0'. This has the minor effect
of treating negative values as EINVAL (with no change to endptr)
rather than ERANGE (with endptr advanced to what was parsed), visible
in the updated iotest output.
We also had no testsuite coverage of "1.1e0k", which happened to parse
under strtod() but is unlikely to occur in practice; as long as we are
making things more robust, it is easy enough to reject the use of
exponents in a strtod parse.
The fix is done by breaking the parse into an integer prefix (no loss
in precision), rejecting negative values (since we can no longer rely
on strtod() to do that), determining if a decimal or hexadecimal parse
was intended (with the new restriction that a fractional hex parse is
not allowed), and where appropriate, using a floating point fractional
parse (where we also scan to reject use of exponents in the fraction).
The bulk of the patch is then updates to the testsuite to match our
new precision, as well as adding new cases we reject (whether they
were rejected or inadvertently accepted before).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20210211204438.1184395-3-eblake@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-02-11 23:44:36 +03:00
|
|
|
assert(mul > 0);
|
2010-10-21 19:15:46 +04:00
|
|
|
}
|
2021-03-15 01:49:30 +03:00
|
|
|
if (mul == 1) {
|
|
|
|
/* When a fraction is present, a scale is required. */
|
|
|
|
if (valf != 0) {
|
|
|
|
endptr = nptr;
|
|
|
|
retval = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
uint64_t valh, tmp;
|
|
|
|
|
|
|
|
/* Compute exact result: 64.64 x 64.0 -> 128.64 fixed point */
|
|
|
|
mulu64(&val, &valh, val, mul);
|
|
|
|
mulu64(&valf, &tmp, valf, mul);
|
|
|
|
val += tmp;
|
|
|
|
valh += val < tmp;
|
|
|
|
|
|
|
|
/* Round 0.5 upward. */
|
|
|
|
tmp = valf >> 63;
|
|
|
|
val += tmp;
|
|
|
|
valh += val < tmp;
|
|
|
|
|
|
|
|
/* Report overflow. */
|
|
|
|
if (valh != 0) {
|
|
|
|
retval = -ERANGE;
|
|
|
|
goto out;
|
|
|
|
}
|
2010-10-21 19:15:46 +04:00
|
|
|
}
|
2021-03-15 01:49:30 +03:00
|
|
|
|
2017-02-21 23:14:06 +03:00
|
|
|
retval = 0;
|
2010-10-21 19:15:46 +04:00
|
|
|
|
2017-02-21 23:14:05 +03:00
|
|
|
out:
|
2010-10-21 19:15:46 +04:00
|
|
|
if (end) {
|
|
|
|
*end = endptr;
|
2023-05-22 22:04:34 +03:00
|
|
|
} else if (nptr && *endptr) {
|
2017-02-21 23:14:05 +03:00
|
|
|
retval = -EINVAL;
|
2010-10-21 19:15:46 +04:00
|
|
|
}
|
2021-03-23 19:52:59 +03:00
|
|
|
if (retval == 0) {
|
|
|
|
*result = val;
|
cutils: Set value in all qemu_strtosz* error paths
Making callers determine whether or not *value was populated on error
is not nice for usability. Pre-patch, we have unit tests that check
that *result is left unchanged on most EINVAL errors and set to 0 on
many ERANGE errors. This is subtly different from libc strtoumax()
behavior which returns UINT64_MAX on ERANGE errors, as well as
different from our parse_uint() which slams to 0 on EINVAL on the
grounds that we want our functions to be harder to mis-use than
strtoumax().
Let's audit callers:
- hw/core/numa.c:parse_numa() fixed in the previous patch to check for
errors
- migration/migration-hmp-cmds.c:hmp_migrate_set_parameter(),
monitor/hmp.c:monitor_parse_arguments(),
qapi/opts-visitor.c:opts_type_size(),
qapi/qobject-input-visitor.c:qobject_input_type_size_keyval(),
qemu-img.c:cvtnum_full(), qemu-io-cmds.c:cvtnum(),
target/i386/cpu.c:x86_cpu_parse_featurestr(), and
util/qemu-option.c:parse_option_size() appear to reject all failures
(although some with distinct messages for ERANGE as opposed to
EINVAL), so it doesn't matter what is in the value parameter on
error.
- All remaining callers are in the testsuite, where we can tweak our
expectations to match our new desired behavior.
Advancing to the end of the string parsed on overflow (ERANGE), while
still returning 0, makes sense (UINT64_MAX as a size is unlikely to be
useful); likewise, our size parsing code is complex enough that it's
easier to always return 0 when endptr is NULL but trailing garbage was
found, rather than trying to return the value of the prefix actually
parsed (no current caller cared about the value of the prefix).
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Hanna Czenczek <hreitz@redhat.com>
Message-Id: <20230522190441.64278-16-eblake@redhat.com>
2023-05-22 22:04:37 +03:00
|
|
|
} else {
|
|
|
|
*result = 0;
|
|
|
|
if (end && retval == -EINVAL) {
|
|
|
|
*end = nptr;
|
|
|
|
}
|
2021-03-23 19:52:59 +03:00
|
|
|
}
|
2010-10-21 19:15:46 +04:00
|
|
|
|
|
|
|
return retval;
|
|
|
|
}
|
2010-12-09 16:17:24 +03:00
|
|
|
|
2018-11-21 19:44:14 +03:00
|
|
|
int qemu_strtosz(const char *nptr, const char **end, uint64_t *result)
|
2011-07-07 18:13:11 +04:00
|
|
|
{
|
2017-02-21 23:14:06 +03:00
|
|
|
return do_strtosz(nptr, end, 'B', 1024, result);
|
2011-07-07 18:13:11 +04:00
|
|
|
}
|
|
|
|
|
2018-11-21 19:44:14 +03:00
|
|
|
int qemu_strtosz_MiB(const char *nptr, const char **end, uint64_t *result)
|
2010-12-09 16:17:24 +03:00
|
|
|
{
|
2017-02-21 23:14:06 +03:00
|
|
|
return do_strtosz(nptr, end, 'M', 1024, result);
|
2010-12-09 16:17:24 +03:00
|
|
|
}
|
2011-09-28 14:41:32 +04:00
|
|
|
|
2018-11-21 19:44:14 +03:00
|
|
|
int qemu_strtosz_metric(const char *nptr, const char **end, uint64_t *result)
|
2017-02-21 23:13:58 +03:00
|
|
|
{
|
2017-02-21 23:14:06 +03:00
|
|
|
return do_strtosz(nptr, end, 'B', 1000, result);
|
2017-02-21 23:13:58 +03:00
|
|
|
}
|
|
|
|
|
2015-07-20 02:02:17 +03:00
|
|
|
/**
|
2017-02-21 23:13:51 +03:00
|
|
|
* Helper function for error checking after strtol() and the like
|
2015-07-20 02:02:17 +03:00
|
|
|
*/
|
2017-02-21 23:13:51 +03:00
|
|
|
static int check_strtox_error(const char *nptr, char *ep,
|
2021-03-23 19:53:00 +03:00
|
|
|
const char **endptr, bool check_zero,
|
|
|
|
int libc_errno)
|
2015-07-20 02:02:17 +03:00
|
|
|
{
|
2018-12-06 18:18:56 +03:00
|
|
|
assert(ep >= nptr);
|
2021-03-23 19:53:00 +03:00
|
|
|
|
|
|
|
/* Windows has a bug in that it fails to parse 0 from "0x" in base 16 */
|
|
|
|
if (check_zero && ep == nptr && libc_errno == 0) {
|
|
|
|
char *tmp;
|
|
|
|
|
|
|
|
errno = 0;
|
|
|
|
if (strtol(nptr, &tmp, 10) == 0 && errno == 0 &&
|
|
|
|
(*tmp == 'x' || *tmp == 'X')) {
|
|
|
|
ep = tmp;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-02-21 23:13:52 +03:00
|
|
|
if (endptr) {
|
|
|
|
*endptr = ep;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Turn "no conversion" into an error */
|
2017-02-21 23:13:51 +03:00
|
|
|
if (libc_errno == 0 && ep == nptr) {
|
2017-02-21 23:13:52 +03:00
|
|
|
return -EINVAL;
|
2015-09-10 11:02:00 +03:00
|
|
|
}
|
2017-02-21 23:13:52 +03:00
|
|
|
|
|
|
|
/* Fail when we're expected to consume the string, but didn't */
|
2017-02-21 23:13:51 +03:00
|
|
|
if (!endptr && *ep) {
|
2015-07-20 02:02:17 +03:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
2017-02-21 23:13:52 +03:00
|
|
|
|
2017-02-21 23:13:51 +03:00
|
|
|
return -libc_errno;
|
2015-07-20 02:02:17 +03:00
|
|
|
}
|
|
|
|
|
2017-12-22 15:46:23 +03:00
|
|
|
/**
|
|
|
|
* Convert string @nptr to an integer, and store it in @result.
|
|
|
|
*
|
|
|
|
* This is a wrapper around strtol() that is harder to misuse.
|
|
|
|
* Semantics of @nptr, @endptr, @base match strtol() with differences
|
|
|
|
* noted below.
|
|
|
|
*
|
|
|
|
* @nptr may be null, and no conversion is performed then.
|
|
|
|
*
|
2023-05-22 22:04:38 +03:00
|
|
|
* If no conversion is performed, store @nptr in *@endptr, 0 in
|
|
|
|
* @result, and return -EINVAL.
|
2017-12-22 15:46:23 +03:00
|
|
|
*
|
|
|
|
* If @endptr is null, and the string isn't fully converted, return
|
2023-05-22 22:04:38 +03:00
|
|
|
* -EINVAL with @result set to the parsed value. This is the case
|
|
|
|
* when the pointer that would be stored in a non-null @endptr points
|
|
|
|
* to a character other than '\0'.
|
2017-12-22 15:46:23 +03:00
|
|
|
*
|
|
|
|
* If the conversion overflows @result, store INT_MAX in @result,
|
|
|
|
* and return -ERANGE.
|
|
|
|
*
|
|
|
|
* If the conversion underflows @result, store INT_MIN in @result,
|
|
|
|
* and return -ERANGE.
|
|
|
|
*
|
|
|
|
* Else store the converted value in @result, and return zero.
|
2023-05-22 22:04:27 +03:00
|
|
|
*
|
|
|
|
* This matches the behavior of strtol() on 32-bit platforms, even on
|
|
|
|
* platforms where long is 64-bits.
|
2017-12-22 15:46:23 +03:00
|
|
|
*/
|
|
|
|
int qemu_strtoi(const char *nptr, const char **endptr, int base,
|
|
|
|
int *result)
|
|
|
|
{
|
|
|
|
char *ep;
|
|
|
|
long long lresult;
|
|
|
|
|
2018-12-06 18:18:56 +03:00
|
|
|
assert((unsigned) base <= 36 && base != 1);
|
2017-12-22 15:46:23 +03:00
|
|
|
if (!nptr) {
|
2023-05-22 22:04:38 +03:00
|
|
|
*result = 0;
|
2017-12-22 15:46:23 +03:00
|
|
|
if (endptr) {
|
|
|
|
*endptr = nptr;
|
|
|
|
}
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
errno = 0;
|
|
|
|
lresult = strtoll(nptr, &ep, base);
|
|
|
|
if (lresult < INT_MIN) {
|
|
|
|
*result = INT_MIN;
|
|
|
|
errno = ERANGE;
|
|
|
|
} else if (lresult > INT_MAX) {
|
|
|
|
*result = INT_MAX;
|
|
|
|
errno = ERANGE;
|
|
|
|
} else {
|
|
|
|
*result = lresult;
|
|
|
|
}
|
2021-03-23 19:53:00 +03:00
|
|
|
return check_strtox_error(nptr, ep, endptr, lresult == 0, errno);
|
2017-12-22 15:46:23 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Convert string @nptr to an unsigned integer, and store it in @result.
|
|
|
|
*
|
|
|
|
* This is a wrapper around strtoul() that is harder to misuse.
|
|
|
|
* Semantics of @nptr, @endptr, @base match strtoul() with differences
|
|
|
|
* noted below.
|
|
|
|
*
|
|
|
|
* @nptr may be null, and no conversion is performed then.
|
|
|
|
*
|
2023-05-22 22:04:38 +03:00
|
|
|
* If no conversion is performed, store @nptr in *@endptr, 0 in
|
|
|
|
* @result, and return -EINVAL.
|
2017-12-22 15:46:23 +03:00
|
|
|
*
|
|
|
|
* If @endptr is null, and the string isn't fully converted, return
|
2023-05-22 22:04:38 +03:00
|
|
|
* -EINVAL with @result set to the parsed value. This is the case
|
|
|
|
* when the pointer that would be stored in a non-null @endptr points
|
|
|
|
* to a character other than '\0'.
|
2017-12-22 15:46:23 +03:00
|
|
|
*
|
|
|
|
* If the conversion overflows @result, store UINT_MAX in @result,
|
|
|
|
* and return -ERANGE.
|
|
|
|
*
|
|
|
|
* Else store the converted value in @result, and return zero.
|
|
|
|
*
|
|
|
|
* Note that a number with a leading minus sign gets converted without
|
|
|
|
* the minus sign, checked for overflow (see above), then negated (in
|
2023-05-22 22:04:27 +03:00
|
|
|
* @result's type). This matches the behavior of strtoul() on 32-bit
|
|
|
|
* platforms, even on platforms where long is 64-bits.
|
2017-12-22 15:46:23 +03:00
|
|
|
*/
|
|
|
|
int qemu_strtoui(const char *nptr, const char **endptr, int base,
|
|
|
|
unsigned int *result)
|
|
|
|
{
|
|
|
|
char *ep;
|
2023-05-22 22:04:27 +03:00
|
|
|
unsigned long long lresult;
|
|
|
|
bool neg;
|
2017-12-22 15:46:23 +03:00
|
|
|
|
2018-12-06 18:18:56 +03:00
|
|
|
assert((unsigned) base <= 36 && base != 1);
|
2017-12-22 15:46:23 +03:00
|
|
|
if (!nptr) {
|
2023-05-22 22:04:38 +03:00
|
|
|
*result = 0;
|
2017-12-22 15:46:23 +03:00
|
|
|
if (endptr) {
|
|
|
|
*endptr = nptr;
|
|
|
|
}
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
errno = 0;
|
|
|
|
lresult = strtoull(nptr, &ep, base);
|
|
|
|
|
|
|
|
/* Windows returns 1 for negative out-of-range values. */
|
|
|
|
if (errno == ERANGE) {
|
|
|
|
*result = -1;
|
|
|
|
} else {
|
2023-05-22 22:04:27 +03:00
|
|
|
/*
|
|
|
|
* Note that platforms with 32-bit strtoul only accept input
|
|
|
|
* in the range [-4294967295, 4294967295]; but we used 64-bit
|
|
|
|
* strtoull which wraps -18446744073709551615 to 1 instead of
|
|
|
|
* declaring overflow. So we must check if '-' was parsed,
|
|
|
|
* and if so, undo the negation before doing our bounds check.
|
|
|
|
*/
|
|
|
|
neg = memchr(nptr, '-', ep - nptr) != NULL;
|
|
|
|
if (neg) {
|
|
|
|
lresult = -lresult;
|
|
|
|
}
|
2017-12-22 15:46:23 +03:00
|
|
|
if (lresult > UINT_MAX) {
|
|
|
|
*result = UINT_MAX;
|
|
|
|
errno = ERANGE;
|
|
|
|
} else {
|
2023-05-22 22:04:27 +03:00
|
|
|
*result = neg ? -lresult : lresult;
|
2017-12-22 15:46:23 +03:00
|
|
|
}
|
|
|
|
}
|
2021-03-23 19:53:00 +03:00
|
|
|
return check_strtox_error(nptr, ep, endptr, lresult == 0, errno);
|
2017-12-22 15:46:23 +03:00
|
|
|
}
|
|
|
|
|
2015-07-20 02:02:17 +03:00
|
|
|
/**
|
2017-02-21 23:13:49 +03:00
|
|
|
* Convert string @nptr to a long integer, and store it in @result.
|
2015-07-20 02:02:17 +03:00
|
|
|
*
|
2017-02-21 23:13:49 +03:00
|
|
|
* This is a wrapper around strtol() that is harder to misuse.
|
|
|
|
* Semantics of @nptr, @endptr, @base match strtol() with differences
|
|
|
|
* noted below.
|
2015-07-20 02:02:17 +03:00
|
|
|
*
|
2017-02-21 23:13:49 +03:00
|
|
|
* @nptr may be null, and no conversion is performed then.
|
2015-07-20 02:02:17 +03:00
|
|
|
*
|
2023-05-22 22:04:38 +03:00
|
|
|
* If no conversion is performed, store @nptr in *@endptr, 0 in
|
|
|
|
* @result, and return -EINVAL.
|
2015-07-20 02:02:17 +03:00
|
|
|
*
|
2017-02-21 23:13:49 +03:00
|
|
|
* If @endptr is null, and the string isn't fully converted, return
|
2023-05-22 22:04:38 +03:00
|
|
|
* -EINVAL with @result set to the parsed value. This is the case
|
|
|
|
* when the pointer that would be stored in a non-null @endptr points
|
|
|
|
* to a character other than '\0'.
|
2017-02-21 23:13:49 +03:00
|
|
|
*
|
|
|
|
* If the conversion overflows @result, store LONG_MAX in @result,
|
|
|
|
* and return -ERANGE.
|
|
|
|
*
|
|
|
|
* If the conversion underflows @result, store LONG_MIN in @result,
|
|
|
|
* and return -ERANGE.
|
|
|
|
*
|
|
|
|
* Else store the converted value in @result, and return zero.
|
2015-07-20 02:02:17 +03:00
|
|
|
*/
|
|
|
|
int qemu_strtol(const char *nptr, const char **endptr, int base,
|
|
|
|
long *result)
|
|
|
|
{
|
2017-02-21 23:13:51 +03:00
|
|
|
char *ep;
|
2017-02-21 23:13:52 +03:00
|
|
|
|
2018-12-06 18:18:56 +03:00
|
|
|
assert((unsigned) base <= 36 && base != 1);
|
2015-07-20 02:02:17 +03:00
|
|
|
if (!nptr) {
|
2023-05-22 22:04:38 +03:00
|
|
|
*result = 0;
|
2015-07-20 02:02:17 +03:00
|
|
|
if (endptr) {
|
|
|
|
*endptr = nptr;
|
|
|
|
}
|
2017-02-21 23:13:52 +03:00
|
|
|
return -EINVAL;
|
2015-07-20 02:02:17 +03:00
|
|
|
}
|
2017-02-21 23:13:52 +03:00
|
|
|
|
|
|
|
errno = 0;
|
|
|
|
*result = strtol(nptr, &ep, base);
|
2021-03-23 19:53:00 +03:00
|
|
|
return check_strtox_error(nptr, ep, endptr, *result == 0, errno);
|
2015-07-20 02:02:17 +03:00
|
|
|
}
|
2015-07-20 02:02:18 +03:00
|
|
|
|
|
|
|
/**
|
2017-02-21 23:13:49 +03:00
|
|
|
* Convert string @nptr to an unsigned long, and store it in @result.
|
|
|
|
*
|
|
|
|
* This is a wrapper around strtoul() that is harder to misuse.
|
|
|
|
* Semantics of @nptr, @endptr, @base match strtoul() with differences
|
|
|
|
* noted below.
|
|
|
|
*
|
|
|
|
* @nptr may be null, and no conversion is performed then.
|
|
|
|
*
|
2023-05-22 22:04:38 +03:00
|
|
|
* If no conversion is performed, store @nptr in *@endptr, 0 in
|
|
|
|
* @result, and return -EINVAL.
|
2017-02-21 23:13:49 +03:00
|
|
|
*
|
|
|
|
* If @endptr is null, and the string isn't fully converted, return
|
2023-05-22 22:04:38 +03:00
|
|
|
* -EINVAL with @result set to the parsed value. This is the case
|
|
|
|
* when the pointer that would be stored in a non-null @endptr points
|
|
|
|
* to a character other than '\0'.
|
2015-07-20 02:02:18 +03:00
|
|
|
*
|
2017-02-21 23:13:49 +03:00
|
|
|
* If the conversion overflows @result, store ULONG_MAX in @result,
|
|
|
|
* and return -ERANGE.
|
2015-07-20 02:02:18 +03:00
|
|
|
*
|
2017-02-21 23:13:49 +03:00
|
|
|
* Else store the converted value in @result, and return zero.
|
2015-07-20 02:02:18 +03:00
|
|
|
*
|
2017-02-21 23:13:49 +03:00
|
|
|
* Note that a number with a leading minus sign gets converted without
|
|
|
|
* the minus sign, checked for overflow (see above), then negated (in
|
|
|
|
* @result's type). This is exactly how strtoul() works.
|
2015-07-20 02:02:18 +03:00
|
|
|
*/
|
|
|
|
int qemu_strtoul(const char *nptr, const char **endptr, int base,
|
|
|
|
unsigned long *result)
|
|
|
|
{
|
2017-02-21 23:13:51 +03:00
|
|
|
char *ep;
|
2017-02-21 23:13:52 +03:00
|
|
|
|
2018-12-06 18:18:56 +03:00
|
|
|
assert((unsigned) base <= 36 && base != 1);
|
2015-07-20 02:02:18 +03:00
|
|
|
if (!nptr) {
|
2023-05-22 22:04:38 +03:00
|
|
|
*result = 0;
|
2015-07-20 02:02:18 +03:00
|
|
|
if (endptr) {
|
|
|
|
*endptr = nptr;
|
|
|
|
}
|
2017-02-21 23:13:52 +03:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
errno = 0;
|
|
|
|
*result = strtoul(nptr, &ep, base);
|
|
|
|
/* Windows returns 1 for negative out-of-range values. */
|
|
|
|
if (errno == ERANGE) {
|
|
|
|
*result = -1;
|
2015-07-20 02:02:18 +03:00
|
|
|
}
|
2021-03-23 19:53:00 +03:00
|
|
|
return check_strtox_error(nptr, ep, endptr, *result == 0, errno);
|
2015-07-20 02:02:18 +03:00
|
|
|
}
|
|
|
|
|
2015-07-20 02:02:19 +03:00
|
|
|
/**
|
2017-02-21 23:13:49 +03:00
|
|
|
* Convert string @nptr to an int64_t.
|
2015-07-20 02:02:19 +03:00
|
|
|
*
|
2017-02-21 23:13:49 +03:00
|
|
|
* Works like qemu_strtol(), except it stores INT64_MAX on overflow,
|
2019-11-25 16:38:45 +03:00
|
|
|
* and INT64_MIN on underflow.
|
2015-07-20 02:02:19 +03:00
|
|
|
*/
|
2017-02-21 23:13:50 +03:00
|
|
|
int qemu_strtoi64(const char *nptr, const char **endptr, int base,
|
2015-07-20 02:02:19 +03:00
|
|
|
int64_t *result)
|
|
|
|
{
|
2017-02-21 23:13:51 +03:00
|
|
|
char *ep;
|
2017-02-21 23:13:52 +03:00
|
|
|
|
2018-12-06 18:18:56 +03:00
|
|
|
assert((unsigned) base <= 36 && base != 1);
|
2015-07-20 02:02:19 +03:00
|
|
|
if (!nptr) {
|
2023-05-22 22:04:38 +03:00
|
|
|
*result = 0;
|
2015-07-20 02:02:19 +03:00
|
|
|
if (endptr) {
|
|
|
|
*endptr = nptr;
|
|
|
|
}
|
2017-02-21 23:13:52 +03:00
|
|
|
return -EINVAL;
|
2015-07-20 02:02:19 +03:00
|
|
|
}
|
2017-02-21 23:13:52 +03:00
|
|
|
|
2019-11-25 16:38:45 +03:00
|
|
|
/* This assumes int64_t is long long TODO relax */
|
|
|
|
QEMU_BUILD_BUG_ON(sizeof(int64_t) != sizeof(long long));
|
2017-02-21 23:13:52 +03:00
|
|
|
errno = 0;
|
|
|
|
*result = strtoll(nptr, &ep, base);
|
2021-03-23 19:53:00 +03:00
|
|
|
return check_strtox_error(nptr, ep, endptr, *result == 0, errno);
|
2015-07-20 02:02:19 +03:00
|
|
|
}
|
|
|
|
|
2015-07-20 02:02:20 +03:00
|
|
|
/**
|
2017-02-21 23:13:49 +03:00
|
|
|
* Convert string @nptr to an uint64_t.
|
2015-07-20 02:02:20 +03:00
|
|
|
*
|
2017-02-21 23:13:49 +03:00
|
|
|
* Works like qemu_strtoul(), except it stores UINT64_MAX on overflow.
|
2023-05-22 22:04:28 +03:00
|
|
|
* (If you want to prohibit negative numbers that wrap around to
|
|
|
|
* positive, use parse_uint()).
|
2015-07-20 02:02:20 +03:00
|
|
|
*/
|
2017-02-21 23:13:50 +03:00
|
|
|
int qemu_strtou64(const char *nptr, const char **endptr, int base,
|
2015-07-20 02:02:20 +03:00
|
|
|
uint64_t *result)
|
|
|
|
{
|
2017-02-21 23:13:51 +03:00
|
|
|
char *ep;
|
2017-02-21 23:13:52 +03:00
|
|
|
|
2018-12-06 18:18:56 +03:00
|
|
|
assert((unsigned) base <= 36 && base != 1);
|
2015-07-20 02:02:20 +03:00
|
|
|
if (!nptr) {
|
2023-05-22 22:04:38 +03:00
|
|
|
*result = 0;
|
2015-07-20 02:02:20 +03:00
|
|
|
if (endptr) {
|
|
|
|
*endptr = nptr;
|
|
|
|
}
|
2017-02-21 23:13:52 +03:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
2019-11-25 16:38:45 +03:00
|
|
|
/* This assumes uint64_t is unsigned long long TODO relax */
|
|
|
|
QEMU_BUILD_BUG_ON(sizeof(uint64_t) != sizeof(unsigned long long));
|
2017-02-21 23:13:52 +03:00
|
|
|
errno = 0;
|
|
|
|
*result = strtoull(nptr, &ep, base);
|
|
|
|
/* Windows returns 1 for negative out-of-range values. */
|
|
|
|
if (errno == ERANGE) {
|
|
|
|
*result = -1;
|
2015-07-20 02:02:20 +03:00
|
|
|
}
|
2021-03-23 19:53:00 +03:00
|
|
|
return check_strtox_error(nptr, ep, endptr, *result == 0, errno);
|
2015-07-20 02:02:20 +03:00
|
|
|
}
|
|
|
|
|
2018-11-21 19:44:13 +03:00
|
|
|
/**
|
|
|
|
* Convert string @nptr to a double.
|
|
|
|
*
|
|
|
|
* This is a wrapper around strtod() that is harder to misuse.
|
|
|
|
* Semantics of @nptr and @endptr match strtod() with differences
|
|
|
|
* noted below.
|
|
|
|
*
|
|
|
|
* @nptr may be null, and no conversion is performed then.
|
|
|
|
*
|
2023-05-22 22:04:40 +03:00
|
|
|
* If no conversion is performed, store @nptr in *@endptr, +0.0 in
|
|
|
|
* @result, and return -EINVAL.
|
2018-11-21 19:44:13 +03:00
|
|
|
*
|
|
|
|
* If @endptr is null, and the string isn't fully converted, return
|
2023-05-22 22:04:40 +03:00
|
|
|
* -EINVAL with @result set to the parsed value. This is the case
|
|
|
|
* when the pointer that would be stored in a non-null @endptr points
|
|
|
|
* to a character other than '\0'.
|
2018-11-21 19:44:13 +03:00
|
|
|
*
|
|
|
|
* If the conversion overflows, store +/-HUGE_VAL in @result, depending
|
|
|
|
* on the sign, and return -ERANGE.
|
|
|
|
*
|
|
|
|
* If the conversion underflows, store +/-0.0 in @result, depending on the
|
|
|
|
* sign, and return -ERANGE.
|
|
|
|
*
|
|
|
|
* Else store the converted value in @result, and return zero.
|
|
|
|
*/
|
|
|
|
int qemu_strtod(const char *nptr, const char **endptr, double *result)
|
|
|
|
{
|
|
|
|
char *ep;
|
|
|
|
|
|
|
|
if (!nptr) {
|
2023-05-22 22:04:40 +03:00
|
|
|
*result = 0.0;
|
2018-11-21 19:44:13 +03:00
|
|
|
if (endptr) {
|
|
|
|
*endptr = nptr;
|
|
|
|
}
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
errno = 0;
|
|
|
|
*result = strtod(nptr, &ep);
|
2021-03-23 19:53:00 +03:00
|
|
|
return check_strtox_error(nptr, ep, endptr, false, errno);
|
2018-11-21 19:44:13 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Convert string @nptr to a finite double.
|
|
|
|
*
|
2023-05-22 22:04:40 +03:00
|
|
|
* Works like qemu_strtod(), except that "NaN", "inf", and strings
|
|
|
|
* that cause ERANGE overflow errors are rejected with -EINVAL as if
|
|
|
|
* no conversion is performed, storing 0.0 into @result regardless of
|
|
|
|
* any sign. -ERANGE failures for underflow still preserve the parsed
|
|
|
|
* sign.
|
2018-11-21 19:44:13 +03:00
|
|
|
*/
|
|
|
|
int qemu_strtod_finite(const char *nptr, const char **endptr, double *result)
|
|
|
|
{
|
2023-05-22 22:04:40 +03:00
|
|
|
const char *tmp;
|
2018-11-21 19:44:13 +03:00
|
|
|
int ret;
|
|
|
|
|
2023-05-22 22:04:40 +03:00
|
|
|
ret = qemu_strtod(nptr, &tmp, result);
|
|
|
|
if (!isfinite(*result)) {
|
2018-11-21 19:44:13 +03:00
|
|
|
if (endptr) {
|
|
|
|
*endptr = nptr;
|
|
|
|
}
|
2023-05-22 22:04:40 +03:00
|
|
|
*result = 0.0;
|
|
|
|
ret = -EINVAL;
|
|
|
|
} else if (endptr) {
|
|
|
|
*endptr = tmp;
|
|
|
|
} else if (*tmp) {
|
2018-11-21 19:44:13 +03:00
|
|
|
ret = -EINVAL;
|
|
|
|
}
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2018-06-29 13:32:10 +03:00
|
|
|
/**
|
|
|
|
* Searches for the first occurrence of 'c' in 's', and returns a pointer
|
|
|
|
* to the trailing null byte if none was found.
|
|
|
|
*/
|
|
|
|
#ifndef HAVE_STRCHRNUL
|
|
|
|
const char *qemu_strchrnul(const char *s, int c)
|
|
|
|
{
|
|
|
|
const char *e = strchr(s, c);
|
|
|
|
if (!e) {
|
|
|
|
e = s + strlen(s);
|
|
|
|
}
|
|
|
|
return e;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2013-02-04 22:27:45 +04:00
|
|
|
/**
|
|
|
|
* parse_uint:
|
|
|
|
*
|
|
|
|
* @s: String to parse
|
2023-05-22 22:04:30 +03:00
|
|
|
* @endptr: Destination for pointer to first character not consumed
|
2013-02-04 22:27:45 +04:00
|
|
|
* @base: integer base, between 2 and 36 inclusive, or 0
|
2023-05-22 22:04:29 +03:00
|
|
|
* @value: Destination for parsed integer value
|
2013-02-04 22:27:45 +04:00
|
|
|
*
|
|
|
|
* Parse unsigned integer
|
|
|
|
*
|
|
|
|
* Parsed syntax is like strtoull()'s: arbitrary whitespace, a single optional
|
|
|
|
* '+' or '-', an optional "0x" if @base is 0 or 16, one or more digits.
|
|
|
|
*
|
2023-05-22 22:04:28 +03:00
|
|
|
* If @s is null, or @s doesn't start with an integer in the syntax
|
|
|
|
* above, set *@value to 0, *@endptr to @s, and return -EINVAL.
|
2013-02-04 22:27:45 +04:00
|
|
|
*
|
|
|
|
* Set *@endptr to point right beyond the parsed integer (even if the integer
|
|
|
|
* overflows or is negative, all digits will be parsed and *@endptr will
|
2023-05-22 22:04:30 +03:00
|
|
|
* point right beyond them). If @endptr is %NULL, any trailing character
|
|
|
|
* instead causes a result of -EINVAL with *@value of 0.
|
2013-02-04 22:27:45 +04:00
|
|
|
*
|
|
|
|
* If the integer is negative, set *@value to 0, and return -ERANGE.
|
2023-05-22 22:04:28 +03:00
|
|
|
* (If you want to allow negative numbers that wrap around within
|
|
|
|
* bounds, use qemu_strtou64()).
|
2013-02-04 22:27:45 +04:00
|
|
|
*
|
|
|
|
* If the integer overflows unsigned long long, set *@value to
|
|
|
|
* ULLONG_MAX, and return -ERANGE.
|
|
|
|
*
|
|
|
|
* Else, set *@value to the parsed integer, and return 0.
|
|
|
|
*/
|
2023-05-22 22:04:29 +03:00
|
|
|
int parse_uint(const char *s, const char **endptr, int base, uint64_t *value)
|
2013-02-04 22:27:45 +04:00
|
|
|
{
|
|
|
|
int r = 0;
|
|
|
|
char *endp = (char *)s;
|
|
|
|
unsigned long long val = 0;
|
|
|
|
|
2018-12-06 18:18:56 +03:00
|
|
|
assert((unsigned) base <= 36 && base != 1);
|
2013-02-04 22:27:45 +04:00
|
|
|
if (!s) {
|
|
|
|
r = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
errno = 0;
|
|
|
|
val = strtoull(s, &endp, base);
|
|
|
|
if (errno) {
|
|
|
|
r = -errno;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (endp == s) {
|
|
|
|
r = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* make sure we reject negative numbers: */
|
2019-05-14 21:03:11 +03:00
|
|
|
while (qemu_isspace(*s)) {
|
2013-02-04 22:27:45 +04:00
|
|
|
s++;
|
|
|
|
}
|
|
|
|
if (*s == '-') {
|
|
|
|
val = 0;
|
|
|
|
r = -ERANGE;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
out:
|
|
|
|
*value = val;
|
2023-05-22 22:04:30 +03:00
|
|
|
if (endptr) {
|
|
|
|
*endptr = endp;
|
|
|
|
} else if (s && *endp) {
|
|
|
|
r = -EINVAL;
|
|
|
|
*value = 0;
|
|
|
|
}
|
2013-02-04 22:27:45 +04:00
|
|
|
return r;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* parse_uint_full:
|
|
|
|
*
|
|
|
|
* @s: String to parse
|
|
|
|
* @base: integer base, between 2 and 36 inclusive, or 0
|
2023-05-22 22:04:29 +03:00
|
|
|
* @value: Destination for parsed integer value
|
2013-02-04 22:27:45 +04:00
|
|
|
*
|
2023-05-22 22:04:30 +03:00
|
|
|
* Parse unsigned integer from entire string, rejecting any trailing slop.
|
2013-02-04 22:27:45 +04:00
|
|
|
*
|
2023-05-22 22:04:30 +03:00
|
|
|
* Shorthand for parse_uint(s, NULL, base, value).
|
2013-02-04 22:27:45 +04:00
|
|
|
*/
|
2023-05-22 22:04:29 +03:00
|
|
|
int parse_uint_full(const char *s, int base, uint64_t *value)
|
2013-02-04 22:27:45 +04:00
|
|
|
{
|
2023-05-22 22:04:30 +03:00
|
|
|
return parse_uint(s, NULL, base, value);
|
2013-02-04 22:27:45 +04:00
|
|
|
}
|
|
|
|
|
2011-09-28 14:41:32 +04:00
|
|
|
int qemu_parse_fd(const char *param)
|
|
|
|
{
|
2014-04-10 12:24:30 +04:00
|
|
|
long fd;
|
|
|
|
char *endptr;
|
2011-09-28 14:41:32 +04:00
|
|
|
|
2014-04-10 12:24:30 +04:00
|
|
|
errno = 0;
|
2011-09-28 14:41:32 +04:00
|
|
|
fd = strtol(param, &endptr, 10);
|
2014-04-10 12:24:30 +04:00
|
|
|
if (param == endptr /* no conversion performed */ ||
|
|
|
|
errno != 0 /* not representable as long; possibly others */ ||
|
|
|
|
*endptr != '\0' /* final string not empty */ ||
|
|
|
|
fd < 0 /* invalid as file descriptor */ ||
|
|
|
|
fd > INT_MAX /* not representable as int */) {
|
2011-09-28 14:41:32 +04:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
return fd;
|
|
|
|
}
|
2012-08-06 22:42:50 +04:00
|
|
|
|
2012-08-06 22:42:51 +04:00
|
|
|
/*
|
|
|
|
* Implementation of ULEB128 (http://en.wikipedia.org/wiki/LEB128)
|
|
|
|
* Input is limited to 14-bit numbers
|
|
|
|
*/
|
|
|
|
int uleb128_encode_small(uint8_t *out, uint32_t n)
|
|
|
|
{
|
|
|
|
g_assert(n <= 0x3fff);
|
|
|
|
if (n < 0x80) {
|
2019-06-10 06:08:51 +03:00
|
|
|
*out = n;
|
2012-08-06 22:42:51 +04:00
|
|
|
return 1;
|
|
|
|
} else {
|
|
|
|
*out++ = (n & 0x7f) | 0x80;
|
2019-06-10 06:08:51 +03:00
|
|
|
*out = n >> 7;
|
2012-08-06 22:42:51 +04:00
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
int uleb128_decode_small(const uint8_t *in, uint32_t *n)
|
|
|
|
{
|
|
|
|
if (!(*in & 0x80)) {
|
2019-06-10 06:08:51 +03:00
|
|
|
*n = *in;
|
2012-08-06 22:42:51 +04:00
|
|
|
return 1;
|
|
|
|
} else {
|
|
|
|
*n = *in++ & 0x7f;
|
|
|
|
/* we exceed 14 bit number */
|
|
|
|
if (*in & 0x80) {
|
|
|
|
return -1;
|
|
|
|
}
|
2019-06-10 06:08:51 +03:00
|
|
|
*n |= *in << 7;
|
2012-08-06 22:42:51 +04:00
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
}
|
2013-03-04 20:41:28 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* helper to parse debug environment variables
|
|
|
|
*/
|
|
|
|
int parse_debug_env(const char *name, int max, int initial)
|
|
|
|
{
|
|
|
|
char *debug_env = getenv(name);
|
|
|
|
char *inv = NULL;
|
2015-02-11 14:30:43 +03:00
|
|
|
long debug;
|
2013-03-04 20:41:28 +04:00
|
|
|
|
|
|
|
if (!debug_env) {
|
|
|
|
return initial;
|
|
|
|
}
|
2015-02-11 14:30:43 +03:00
|
|
|
errno = 0;
|
2013-03-04 20:41:28 +04:00
|
|
|
debug = strtol(debug_env, &inv, 10);
|
|
|
|
if (inv == debug_env) {
|
|
|
|
return initial;
|
|
|
|
}
|
2015-02-11 14:30:43 +03:00
|
|
|
if (debug < 0 || debug > max || errno != 0) {
|
2017-08-18 21:47:35 +03:00
|
|
|
warn_report("%s not in [0, %d]", name, max);
|
2013-03-04 20:41:28 +04:00
|
|
|
return initial;
|
|
|
|
}
|
|
|
|
return debug;
|
|
|
|
}
|
2014-03-11 03:42:26 +04:00
|
|
|
|
2022-05-25 16:38:48 +03:00
|
|
|
const char *si_prefix(unsigned int exp10)
|
|
|
|
{
|
|
|
|
static const char *prefixes[] = {
|
|
|
|
"a", "f", "p", "n", "u", "m", "", "K", "M", "G", "T", "P", "E"
|
|
|
|
};
|
|
|
|
|
|
|
|
exp10 += 18;
|
|
|
|
assert(exp10 % 3 == 0 && exp10 / 3 < ARRAY_SIZE(prefixes));
|
|
|
|
return prefixes[exp10 / 3];
|
|
|
|
}
|
|
|
|
|
|
|
|
const char *iec_binary_prefix(unsigned int exp2)
|
|
|
|
{
|
|
|
|
static const char *prefixes[] = { "", "Ki", "Mi", "Gi", "Ti", "Pi", "Ei" };
|
|
|
|
|
|
|
|
assert(exp2 % 10 == 0 && exp2 / 10 < ARRAY_SIZE(prefixes));
|
|
|
|
return prefixes[exp2 / 10];
|
|
|
|
}
|
|
|
|
|
2017-05-12 07:17:40 +03:00
|
|
|
/*
|
|
|
|
* Return human readable string for size @val.
|
|
|
|
* @val can be anything that uint64_t allows (no more than "16 EiB").
|
|
|
|
* Use IEC binary units like KiB, MiB, and so forth.
|
|
|
|
* Caller is responsible for passing it to g_free().
|
|
|
|
*/
|
|
|
|
char *size_to_str(uint64_t val)
|
|
|
|
{
|
2019-04-17 20:11:00 +03:00
|
|
|
uint64_t div;
|
2017-05-12 07:17:40 +03:00
|
|
|
int i;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The exponent (returned in i) minus one gives us
|
|
|
|
* floor(log2(val * 1024 / 1000). The correction makes us
|
|
|
|
* switch to the higher power when the integer part is >= 1000.
|
|
|
|
* (see e41b509d68afb1f for more info)
|
|
|
|
*/
|
|
|
|
frexp(val / (1000.0 / 1024.0), &i);
|
2022-05-25 16:38:48 +03:00
|
|
|
i = (i - 1) / 10 * 10;
|
|
|
|
div = 1ULL << i;
|
2017-05-12 07:17:40 +03:00
|
|
|
|
2022-05-25 16:38:48 +03:00
|
|
|
return g_strdup_printf("%0.3g %sB", (double)val / div, iec_binary_prefix(i));
|
2017-05-12 07:17:40 +03:00
|
|
|
}
|
2018-09-07 09:44:33 +03:00
|
|
|
|
2020-10-12 12:57:44 +03:00
|
|
|
char *freq_to_str(uint64_t freq_hz)
|
|
|
|
{
|
|
|
|
double freq = freq_hz;
|
2022-05-25 16:38:48 +03:00
|
|
|
size_t exp10 = 0;
|
2020-10-12 12:57:44 +03:00
|
|
|
|
2020-11-17 15:56:32 +03:00
|
|
|
while (freq >= 1000.0) {
|
2020-10-12 12:57:44 +03:00
|
|
|
freq /= 1000.0;
|
2022-05-25 16:38:48 +03:00
|
|
|
exp10 += 3;
|
2020-10-12 12:57:44 +03:00
|
|
|
}
|
|
|
|
|
2022-05-25 16:38:48 +03:00
|
|
|
return g_strdup_printf("%0.3g %sHz", freq, si_prefix(exp10));
|
2020-10-12 12:57:44 +03:00
|
|
|
}
|
|
|
|
|
2018-09-07 09:44:33 +03:00
|
|
|
int qemu_pstrcmp0(const char **str1, const char **str2)
|
|
|
|
{
|
|
|
|
return g_strcmp0(*str1, *str2);
|
|
|
|
}
|
2020-08-18 12:55:47 +03:00
|
|
|
|
|
|
|
static inline bool starts_with_prefix(const char *dir)
|
|
|
|
{
|
|
|
|
size_t prefix_len = strlen(CONFIG_PREFIX);
|
2023-10-05 15:48:50 +03:00
|
|
|
/*
|
|
|
|
* dir[prefix_len] is only accessed if the length of dir is
|
|
|
|
* >= prefix_len, so no out of bounds access is possible.
|
|
|
|
*/
|
|
|
|
#pragma GCC diagnostic push
|
|
|
|
#if !defined(__clang__) || __has_warning("-Warray-bounds=")
|
|
|
|
#pragma GCC diagnostic ignored "-Warray-bounds="
|
|
|
|
#endif
|
2020-08-18 12:55:47 +03:00
|
|
|
return !memcmp(dir, CONFIG_PREFIX, prefix_len) &&
|
|
|
|
(!dir[prefix_len] || G_IS_DIR_SEPARATOR(dir[prefix_len]));
|
2023-10-05 15:48:50 +03:00
|
|
|
#pragma GCC diagnostic pop
|
2020-08-18 12:55:47 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Return the next path component in dir, and store its length in *p_len. */
|
|
|
|
static inline const char *next_component(const char *dir, int *p_len)
|
|
|
|
{
|
|
|
|
int len;
|
2021-02-08 23:57:52 +03:00
|
|
|
while ((*dir && G_IS_DIR_SEPARATOR(*dir)) ||
|
|
|
|
(*dir == '.' && (G_IS_DIR_SEPARATOR(dir[1]) || dir[1] == '\0'))) {
|
2020-08-18 12:55:47 +03:00
|
|
|
dir++;
|
|
|
|
}
|
|
|
|
len = 0;
|
|
|
|
while (dir[len] && !G_IS_DIR_SEPARATOR(dir[len])) {
|
|
|
|
len++;
|
|
|
|
}
|
|
|
|
*p_len = len;
|
|
|
|
return dir;
|
|
|
|
}
|
|
|
|
|
2022-05-25 17:41:26 +03:00
|
|
|
static const char *exec_dir;
|
|
|
|
|
|
|
|
void qemu_init_exec_dir(const char *argv0)
|
|
|
|
{
|
|
|
|
#ifdef G_OS_WIN32
|
|
|
|
char *p;
|
|
|
|
char buf[MAX_PATH];
|
|
|
|
DWORD len;
|
|
|
|
|
|
|
|
if (exec_dir) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
len = GetModuleFileName(NULL, buf, sizeof(buf) - 1);
|
|
|
|
if (len == 0) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
buf[len] = 0;
|
|
|
|
p = buf + len - 1;
|
|
|
|
while (p != buf && *p != '\\') {
|
|
|
|
p--;
|
|
|
|
}
|
|
|
|
*p = 0;
|
|
|
|
if (access(buf, R_OK) == 0) {
|
|
|
|
exec_dir = g_strdup(buf);
|
|
|
|
} else {
|
|
|
|
exec_dir = CONFIG_BINDIR;
|
|
|
|
}
|
|
|
|
#else
|
|
|
|
char *p = NULL;
|
|
|
|
char buf[PATH_MAX];
|
|
|
|
|
|
|
|
if (exec_dir) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
#if defined(__linux__)
|
|
|
|
{
|
|
|
|
int len;
|
|
|
|
len = readlink("/proc/self/exe", buf, sizeof(buf) - 1);
|
|
|
|
if (len > 0) {
|
|
|
|
buf[len] = 0;
|
|
|
|
p = buf;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#elif defined(__FreeBSD__) \
|
|
|
|
|| (defined(__NetBSD__) && defined(KERN_PROC_PATHNAME))
|
|
|
|
{
|
|
|
|
#if defined(__FreeBSD__)
|
|
|
|
static int mib[4] = {CTL_KERN, KERN_PROC, KERN_PROC_PATHNAME, -1};
|
|
|
|
#else
|
|
|
|
static int mib[4] = {CTL_KERN, KERN_PROC_ARGS, -1, KERN_PROC_PATHNAME};
|
|
|
|
#endif
|
|
|
|
size_t len = sizeof(buf) - 1;
|
|
|
|
|
|
|
|
*buf = '\0';
|
|
|
|
if (!sysctl(mib, ARRAY_SIZE(mib), buf, &len, NULL, 0) &&
|
|
|
|
*buf) {
|
|
|
|
buf[sizeof(buf) - 1] = '\0';
|
|
|
|
p = buf;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#elif defined(__APPLE__)
|
|
|
|
{
|
|
|
|
char fpath[PATH_MAX];
|
|
|
|
uint32_t len = sizeof(fpath);
|
|
|
|
if (_NSGetExecutablePath(fpath, &len) == 0) {
|
|
|
|
p = realpath(fpath, buf);
|
|
|
|
if (!p) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#elif defined(__HAIKU__)
|
|
|
|
{
|
|
|
|
image_info ii;
|
|
|
|
int32_t c = 0;
|
|
|
|
|
|
|
|
*buf = '\0';
|
|
|
|
while (get_next_image_info(0, &c, &ii) == B_OK) {
|
|
|
|
if (ii.type == B_APP_IMAGE) {
|
|
|
|
strncpy(buf, ii.name, sizeof(buf));
|
|
|
|
buf[sizeof(buf) - 1] = 0;
|
|
|
|
p = buf;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
/* If we don't have any way of figuring out the actual executable
|
|
|
|
location then try argv[0]. */
|
|
|
|
if (!p && argv0) {
|
|
|
|
p = realpath(argv0, buf);
|
|
|
|
}
|
|
|
|
if (p) {
|
|
|
|
exec_dir = g_path_get_dirname(p);
|
|
|
|
} else {
|
|
|
|
exec_dir = CONFIG_BINDIR;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2020-08-18 12:55:47 +03:00
|
|
|
char *get_relocated_path(const char *dir)
|
|
|
|
{
|
|
|
|
size_t prefix_len = strlen(CONFIG_PREFIX);
|
|
|
|
const char *bindir = CONFIG_BINDIR;
|
|
|
|
GString *result;
|
|
|
|
int len_dir, len_bindir;
|
|
|
|
|
|
|
|
/* Fail if qemu_init_exec_dir was not called. */
|
|
|
|
assert(exec_dir[0]);
|
|
|
|
|
|
|
|
result = g_string_new(exec_dir);
|
2022-06-24 17:50:37 +03:00
|
|
|
g_string_append(result, "/qemu-bundle");
|
|
|
|
if (access(result->str, R_OK) == 0) {
|
|
|
|
#ifdef G_OS_WIN32
|
2023-10-05 09:47:25 +03:00
|
|
|
const char *src = dir;
|
|
|
|
size_t size = mbsrtowcs(NULL, &src, 0, &(mbstate_t){0}) + 1;
|
2022-06-24 17:50:37 +03:00
|
|
|
PWSTR wdir = g_new(WCHAR, size);
|
2023-10-05 09:47:25 +03:00
|
|
|
mbsrtowcs(wdir, &src, size, &(mbstate_t){0});
|
2022-06-24 17:50:37 +03:00
|
|
|
|
|
|
|
PCWSTR wdir_skipped_root;
|
2023-10-05 09:47:25 +03:00
|
|
|
if (PathCchSkipRoot(wdir, &wdir_skipped_root) == S_OK) {
|
|
|
|
size = wcsrtombs(NULL, &wdir_skipped_root, 0, &(mbstate_t){0});
|
|
|
|
char *cursor = result->str + result->len;
|
|
|
|
g_string_set_size(result, result->len + size);
|
|
|
|
wcsrtombs(cursor, &wdir_skipped_root, size + 1, &(mbstate_t){0});
|
|
|
|
} else {
|
|
|
|
g_string_append(result, dir);
|
|
|
|
}
|
2022-06-24 17:50:37 +03:00
|
|
|
|
|
|
|
g_free(wdir);
|
|
|
|
#else
|
|
|
|
g_string_append(result, dir);
|
|
|
|
#endif
|
meson, cutils: allow non-relocatable installs
Say QEMU is configured with bindir = "/usr/bin" and a firmware path
that starts with "/usr/share/qemu". Ever since QEMU 5.2, QEMU's
install has been relocatable: if you move qemu-system-x86_64 from
/usr/bin to /home/username/bin, it will start looking for firmware in
/home/username/share/qemu. Previously, you would get a non-relocatable
install where the moved QEMU will keep looking for firmware in
/usr/share/qemu.
Windows almost always wants relocatable installs, and in fact that
is why QEMU 5.2 introduced relocatability in the first place.
However, newfangled distribution mechanisms such as AppImage
(https://docs.appimage.org/reference/best-practices.html), and
possibly NixOS, also dislike using at runtime the absolute paths
that were established at build time.
On POSIX systems you almost never care; if you do, your usecase
dictates which one is desirable, so there's no single answer.
Obviously relocatability works fine most of the time, because not many
people have complained about QEMU's switch to relocatable install,
and that's why until now there was no way to disable relocatability.
But a non-relocatable, non-modular binary can help if you want to do
experiments with old firmware and new QEMU or vice versa (because you
can just upgrade/downgrade the firmware package, and use rpm2cpio or
similar to extract the QEMU binaries outside /usr), so allow both.
This patch allows one to build a non-relocatable install using a new
option to configure. Why? Because it's not too hard, and because
it helps the user double check the relocatability of their install.
Note that the same code that handles relocation also lets you run QEMU
from the build tree and pick e.g. firmware files from the source tree
transparently. Therefore that part remains active with this patch,
even if you configure with --disable-relocatable.
Suggested-by: Michael Tokarev <mjt@tls.msk.ru>
Reviewed-by: Emmanouil Pitsidianakis <manos.pitsidianakis@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-10-05 15:19:34 +03:00
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (IS_ENABLED(CONFIG_RELOCATABLE) &&
|
|
|
|
starts_with_prefix(dir) && starts_with_prefix(bindir)) {
|
2022-06-24 17:50:37 +03:00
|
|
|
g_string_assign(result, exec_dir);
|
|
|
|
|
|
|
|
/* Advance over common components. */
|
|
|
|
len_dir = len_bindir = prefix_len;
|
|
|
|
do {
|
|
|
|
dir += len_dir;
|
|
|
|
bindir += len_bindir;
|
|
|
|
dir = next_component(dir, &len_dir);
|
|
|
|
bindir = next_component(bindir, &len_bindir);
|
|
|
|
} while (len_dir && len_dir == len_bindir && !memcmp(dir, bindir, len_dir));
|
|
|
|
|
|
|
|
/* Ascend from bindir to the common prefix with dir. */
|
|
|
|
while (len_bindir) {
|
|
|
|
bindir += len_bindir;
|
|
|
|
g_string_append(result, "/..");
|
|
|
|
bindir = next_component(bindir, &len_bindir);
|
|
|
|
}
|
2020-08-18 12:55:47 +03:00
|
|
|
|
2022-06-24 17:50:37 +03:00
|
|
|
if (*dir) {
|
|
|
|
assert(G_IS_DIR_SEPARATOR(dir[-1]));
|
|
|
|
g_string_append(result, dir - 1);
|
|
|
|
}
|
meson, cutils: allow non-relocatable installs
Say QEMU is configured with bindir = "/usr/bin" and a firmware path
that starts with "/usr/share/qemu". Ever since QEMU 5.2, QEMU's
install has been relocatable: if you move qemu-system-x86_64 from
/usr/bin to /home/username/bin, it will start looking for firmware in
/home/username/share/qemu. Previously, you would get a non-relocatable
install where the moved QEMU will keep looking for firmware in
/usr/share/qemu.
Windows almost always wants relocatable installs, and in fact that
is why QEMU 5.2 introduced relocatability in the first place.
However, newfangled distribution mechanisms such as AppImage
(https://docs.appimage.org/reference/best-practices.html), and
possibly NixOS, also dislike using at runtime the absolute paths
that were established at build time.
On POSIX systems you almost never care; if you do, your usecase
dictates which one is desirable, so there's no single answer.
Obviously relocatability works fine most of the time, because not many
people have complained about QEMU's switch to relocatable install,
and that's why until now there was no way to disable relocatability.
But a non-relocatable, non-modular binary can help if you want to do
experiments with old firmware and new QEMU or vice versa (because you
can just upgrade/downgrade the firmware package, and use rpm2cpio or
similar to extract the QEMU binaries outside /usr), so allow both.
This patch allows one to build a non-relocatable install using a new
option to configure. Why? Because it's not too hard, and because
it helps the user double check the relocatability of their install.
Note that the same code that handles relocation also lets you run QEMU
from the build tree and pick e.g. firmware files from the source tree
transparently. Therefore that part remains active with this patch,
even if you configure with --disable-relocatable.
Suggested-by: Michael Tokarev <mjt@tls.msk.ru>
Reviewed-by: Emmanouil Pitsidianakis <manos.pitsidianakis@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-10-05 15:19:34 +03:00
|
|
|
goto out;
|
2020-08-18 12:55:47 +03:00
|
|
|
}
|
|
|
|
|
meson, cutils: allow non-relocatable installs
Say QEMU is configured with bindir = "/usr/bin" and a firmware path
that starts with "/usr/share/qemu". Ever since QEMU 5.2, QEMU's
install has been relocatable: if you move qemu-system-x86_64 from
/usr/bin to /home/username/bin, it will start looking for firmware in
/home/username/share/qemu. Previously, you would get a non-relocatable
install where the moved QEMU will keep looking for firmware in
/usr/share/qemu.
Windows almost always wants relocatable installs, and in fact that
is why QEMU 5.2 introduced relocatability in the first place.
However, newfangled distribution mechanisms such as AppImage
(https://docs.appimage.org/reference/best-practices.html), and
possibly NixOS, also dislike using at runtime the absolute paths
that were established at build time.
On POSIX systems you almost never care; if you do, your usecase
dictates which one is desirable, so there's no single answer.
Obviously relocatability works fine most of the time, because not many
people have complained about QEMU's switch to relocatable install,
and that's why until now there was no way to disable relocatability.
But a non-relocatable, non-modular binary can help if you want to do
experiments with old firmware and new QEMU or vice versa (because you
can just upgrade/downgrade the firmware package, and use rpm2cpio or
similar to extract the QEMU binaries outside /usr), so allow both.
This patch allows one to build a non-relocatable install using a new
option to configure. Why? Because it's not too hard, and because
it helps the user double check the relocatability of their install.
Note that the same code that handles relocation also lets you run QEMU
from the build tree and pick e.g. firmware files from the source tree
transparently. Therefore that part remains active with this patch,
even if you configure with --disable-relocatable.
Suggested-by: Michael Tokarev <mjt@tls.msk.ru>
Reviewed-by: Emmanouil Pitsidianakis <manos.pitsidianakis@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-10-05 15:19:34 +03:00
|
|
|
g_string_assign(result, dir);
|
|
|
|
out:
|
2021-04-12 20:02:55 +03:00
|
|
|
return g_string_free(result, false);
|
2020-08-18 12:55:47 +03:00
|
|
|
}
|