keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
/*
|
|
|
|
* Unit tests for parsing of KEY=VALUE,... strings
|
|
|
|
*
|
|
|
|
* Copyright (C) 2017 Red Hat Inc.
|
|
|
|
*
|
|
|
|
* Authors:
|
|
|
|
* Markus Armbruster <armbru@redhat.com>,
|
|
|
|
*
|
|
|
|
* This work is licensed under the terms of the GNU GPL, version 2 or later.
|
|
|
|
* See the COPYING file in the top-level directory.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "qemu/osdep.h"
|
2018-06-25 15:41:57 +03:00
|
|
|
#include "qemu/units.h"
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
#include "qapi/error.h"
|
2018-02-01 14:18:39 +03:00
|
|
|
#include "qapi/qmp/qdict.h"
|
2018-02-01 14:18:38 +03:00
|
|
|
#include "qapi/qmp/qlist.h"
|
keyval: Support lists
Additionally permit non-negative integers as key components. A
dictionary's keys must either be all integers or none. If all keys
are integers, convert the dictionary to a list. The set of keys must
be [0,N].
Examples:
* list.1=goner,list.0=null,list.1=eins,list.2=zwei
is equivalent to JSON [ "null", "eins", "zwei" ]
* a.b.c=1,a.b.0=2
is inconsistent: a.b.c clashes with a.b.0
* list.0=null,list.2=eins,list.2=zwei
has a hole: list.1 is missing
Similar design flaw as for objects: there is no way to denote an empty
list. While interpreting "key absent" as empty list seems natural
(removing a list member from the input string works when there are
multiple ones, so why not when there's just one), it doesn't work:
"key absent" already means "optional list absent", which isn't the
same as "empty list present".
Update the keyval object visitor to use this a.0 syntax in error
messages rather than the usual a[0].
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-25-git-send-email-armbru@redhat.com>
[Off-by-one fix squashed in, as per Kevin's review]
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2017-03-01 00:27:10 +03:00
|
|
|
#include "qapi/qmp/qstring.h"
|
2017-03-01 00:26:51 +03:00
|
|
|
#include "qapi/qobject-input-visitor.h"
|
2017-03-20 15:55:46 +03:00
|
|
|
#include "test-qapi-visit.h"
|
2017-03-01 00:26:51 +03:00
|
|
|
#include "qemu/cutils.h"
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
#include "qemu/option.h"
|
|
|
|
|
|
|
|
static void test_keyval_parse(void)
|
|
|
|
{
|
|
|
|
Error *err = NULL;
|
|
|
|
QDict *qdict, *sub_qdict;
|
|
|
|
char long_key[129];
|
|
|
|
char *params;
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
bool help;
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
|
|
|
|
/* Nothing */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("", NULL, NULL, &error_abort);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
g_assert_cmpuint(qdict_size(qdict), ==, 0);
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
|
|
|
|
/* Empty key (qemu_opts_parse() accepts this) */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("=val", NULL, NULL, &err);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
error_free_or_abort(&err);
|
|
|
|
g_assert(!qdict);
|
|
|
|
|
|
|
|
/* Empty key fragment */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse(".", NULL, NULL, &err);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
error_free_or_abort(&err);
|
|
|
|
g_assert(!qdict);
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("key.", NULL, NULL, &err);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
error_free_or_abort(&err);
|
|
|
|
g_assert(!qdict);
|
|
|
|
|
2017-03-01 00:27:05 +03:00
|
|
|
/* Invalid non-empty key (qemu_opts_parse() doesn't care) */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("7up=val", NULL, NULL, &err);
|
2017-03-01 00:27:05 +03:00
|
|
|
error_free_or_abort(&err);
|
|
|
|
g_assert(!qdict);
|
|
|
|
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
/* Overlong key */
|
|
|
|
memset(long_key, 'a', 127);
|
|
|
|
long_key[127] = 'z';
|
|
|
|
long_key[128] = 0;
|
|
|
|
params = g_strdup_printf("k.%s=v", long_key);
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse(params + 2, NULL, NULL, &err);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
error_free_or_abort(&err);
|
|
|
|
g_assert(!qdict);
|
|
|
|
|
|
|
|
/* Overlong key fragment */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse(params, NULL, NULL, &err);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
error_free_or_abort(&err);
|
|
|
|
g_assert(!qdict);
|
|
|
|
g_free(params);
|
|
|
|
|
|
|
|
/* Long key (qemu_opts_parse() accepts and truncates silently) */
|
|
|
|
params = g_strdup_printf("k.%s=v", long_key + 1);
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse(params + 2, NULL, NULL, &error_abort);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
g_assert_cmpuint(qdict_size(qdict), ==, 1);
|
|
|
|
g_assert_cmpstr(qdict_get_try_str(qdict, long_key + 1), ==, "v");
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
|
|
|
|
/* Long key fragment */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse(params, NULL, NULL, &error_abort);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
g_assert_cmpuint(qdict_size(qdict), ==, 1);
|
|
|
|
sub_qdict = qdict_get_qdict(qdict, "k");
|
|
|
|
g_assert(sub_qdict);
|
|
|
|
g_assert_cmpuint(qdict_size(sub_qdict), ==, 1);
|
|
|
|
g_assert_cmpstr(qdict_get_try_str(sub_qdict, long_key + 1), ==, "v");
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
g_free(params);
|
|
|
|
|
2017-03-01 00:27:05 +03:00
|
|
|
/* Crap after valid key */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("key[0]=val", NULL, NULL, &err);
|
2017-03-01 00:27:05 +03:00
|
|
|
error_free_or_abort(&err);
|
|
|
|
g_assert(!qdict);
|
|
|
|
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
/* Multiple keys, last one wins */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("a=1,b=2,,x,a=3", NULL, NULL, &error_abort);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
g_assert_cmpuint(qdict_size(qdict), ==, 2);
|
|
|
|
g_assert_cmpstr(qdict_get_try_str(qdict, "a"), ==, "3");
|
|
|
|
g_assert_cmpstr(qdict_get_try_str(qdict, "b"), ==, "2,x");
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
|
|
|
|
/* Even when it doesn't in qemu_opts_parse() */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("id=foo,id=bar", NULL, NULL, &error_abort);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
g_assert_cmpuint(qdict_size(qdict), ==, 1);
|
|
|
|
g_assert_cmpstr(qdict_get_try_str(qdict, "id"), ==, "bar");
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
|
|
|
|
/* Dotted keys */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("a.b.c=1,a.b.c=2,d=3", NULL, NULL, &error_abort);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
g_assert_cmpuint(qdict_size(qdict), ==, 2);
|
|
|
|
sub_qdict = qdict_get_qdict(qdict, "a");
|
|
|
|
g_assert(sub_qdict);
|
|
|
|
g_assert_cmpuint(qdict_size(sub_qdict), ==, 1);
|
|
|
|
sub_qdict = qdict_get_qdict(sub_qdict, "b");
|
|
|
|
g_assert(sub_qdict);
|
|
|
|
g_assert_cmpuint(qdict_size(sub_qdict), ==, 1);
|
|
|
|
g_assert_cmpstr(qdict_get_try_str(sub_qdict, "c"), ==, "2");
|
|
|
|
g_assert_cmpstr(qdict_get_try_str(qdict, "d"), ==, "3");
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
|
|
|
|
/* Inconsistent dotted keys */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("a.b=1,a=2", NULL, NULL, &err);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
error_free_or_abort(&err);
|
|
|
|
g_assert(!qdict);
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("a.b=1,a.b.c=2", NULL, NULL, &err);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
error_free_or_abort(&err);
|
|
|
|
g_assert(!qdict);
|
|
|
|
|
|
|
|
/* Trailing comma is ignored */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("x=y,", NULL, NULL, &error_abort);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
g_assert_cmpuint(qdict_size(qdict), ==, 1);
|
|
|
|
g_assert_cmpstr(qdict_get_try_str(qdict, "x"), ==, "y");
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
|
|
|
|
/* Except when it isn't */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse(",", NULL, NULL, &err);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
error_free_or_abort(&err);
|
|
|
|
g_assert(!qdict);
|
|
|
|
|
|
|
|
/* Value containing ,id= not misinterpreted as qemu_opts_parse() does */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("x=,,id=bar", NULL, NULL, &error_abort);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
g_assert_cmpuint(qdict_size(qdict), ==, 1);
|
|
|
|
g_assert_cmpstr(qdict_get_try_str(qdict, "x"), ==, ",id=bar");
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
|
|
|
|
/* Anti-social ID is left to caller (qemu_opts_parse() rejects it) */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("id=666", NULL, NULL, &error_abort);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
g_assert_cmpuint(qdict_size(qdict), ==, 1);
|
|
|
|
g_assert_cmpstr(qdict_get_try_str(qdict, "id"), ==, "666");
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
|
|
|
|
/* Implied value not supported (unlike qemu_opts_parse()) */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("an,noaus,noaus=", NULL, NULL, &err);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
error_free_or_abort(&err);
|
|
|
|
g_assert(!qdict);
|
|
|
|
|
|
|
|
/* Implied value, key "no" (qemu_opts_parse(): negated empty key) */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("no", NULL, NULL, &err);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
error_free_or_abort(&err);
|
|
|
|
g_assert(!qdict);
|
|
|
|
|
|
|
|
/* Implied key */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("an,aus=off,noaus=", "implied", NULL, &error_abort);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
g_assert_cmpuint(qdict_size(qdict), ==, 3);
|
|
|
|
g_assert_cmpstr(qdict_get_try_str(qdict, "implied"), ==, "an");
|
|
|
|
g_assert_cmpstr(qdict_get_try_str(qdict, "aus"), ==, "off");
|
|
|
|
g_assert_cmpstr(qdict_get_try_str(qdict, "noaus"), ==, "");
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
|
|
|
|
/* Implied dotted key */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("val", "eins.zwei", NULL, &error_abort);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
g_assert_cmpuint(qdict_size(qdict), ==, 1);
|
|
|
|
sub_qdict = qdict_get_qdict(qdict, "eins");
|
|
|
|
g_assert(sub_qdict);
|
|
|
|
g_assert_cmpuint(qdict_size(sub_qdict), ==, 1);
|
|
|
|
g_assert_cmpstr(qdict_get_try_str(sub_qdict, "zwei"), ==, "val");
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
|
|
|
|
/* Implied key with empty value (qemu_opts_parse() accepts this) */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse(",", "implied", NULL, &err);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
error_free_or_abort(&err);
|
|
|
|
g_assert(!qdict);
|
|
|
|
|
|
|
|
/* Likewise (qemu_opts_parse(): implied key with comma value) */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse(",,,a=1", "implied", NULL, &err);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
error_free_or_abort(&err);
|
|
|
|
g_assert(!qdict);
|
|
|
|
|
2020-10-11 10:35:00 +03:00
|
|
|
/* Implied key's value can't have comma (qemu_opts_parse(): it can) */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("val,,ue", "implied", NULL, &err);
|
keyval: Fix parsing of ',' in value of implied key
The previous commit demonstrated documentation and code disagree on
parsing of ',' in the value of an implied key. Fix the code to match
the documentation.
This breaks uses of keyval_parse() that pass an implied key and accept
a value containing ','. None of the existing uses does:
* audiodev: implied key "driver" is enum AudiodevDriver, none of the
values contains ','
* display: implied key "type" is enum DisplayType, none of the values
contains ','
* blockdev: implied key "driver is enum BlockdevDriver, none of the
values contains ','
* export: implied key "type" is enum BlockExportType, none of the
values contains ','
* monitor: implied key "mode" is enum MonitorMode, none of the values
contains ','
* nbd-server: no implied key.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-4-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:01 +03:00
|
|
|
error_free_or_abort(&err);
|
|
|
|
g_assert(!qdict);
|
2020-10-11 10:35:00 +03:00
|
|
|
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
/* Empty key is not an implied key */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("=val", "implied", NULL, &err);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
error_free_or_abort(&err);
|
|
|
|
g_assert(!qdict);
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
|
|
|
|
/* "help" by itself, without implied key */
|
|
|
|
qdict = keyval_parse("help", NULL, &help, &error_abort);
|
|
|
|
g_assert_cmpuint(qdict_size(qdict), ==, 0);
|
|
|
|
g_assert(help);
|
|
|
|
qobject_unref(qdict);
|
|
|
|
|
|
|
|
/* "help" by itself, with implied key */
|
|
|
|
qdict = keyval_parse("help", "implied", &help, &error_abort);
|
|
|
|
g_assert_cmpuint(qdict_size(qdict), ==, 0);
|
|
|
|
g_assert(help);
|
|
|
|
qobject_unref(qdict);
|
|
|
|
|
|
|
|
/* "help" when no help is available, without implied key */
|
|
|
|
qdict = keyval_parse("help", NULL, NULL, &err);
|
|
|
|
error_free_or_abort(&err);
|
|
|
|
g_assert(!qdict);
|
|
|
|
|
|
|
|
/* "help" when no help is available, with implied key */
|
|
|
|
qdict = keyval_parse("help", "implied", NULL, &err);
|
|
|
|
error_free_or_abort(&err);
|
|
|
|
g_assert(!qdict);
|
|
|
|
|
|
|
|
/* Key "help" */
|
|
|
|
qdict = keyval_parse("help=on", NULL, &help, &error_abort);
|
|
|
|
g_assert_cmpuint(qdict_size(qdict), ==, 1);
|
|
|
|
g_assert_cmpstr(qdict_get_try_str(qdict, "help"), ==, "on");
|
|
|
|
g_assert(!help);
|
|
|
|
qobject_unref(qdict);
|
|
|
|
|
|
|
|
/* "help" followed by crap, without implied key */
|
|
|
|
qdict = keyval_parse("help.abc", NULL, &help, &err);
|
|
|
|
error_free_or_abort(&err);
|
|
|
|
g_assert(!qdict);
|
|
|
|
|
|
|
|
/* "help" followed by crap, with implied key */
|
|
|
|
qdict = keyval_parse("help.abc", "implied", &help, &err);
|
|
|
|
g_assert_cmpuint(qdict_size(qdict), ==, 1);
|
|
|
|
g_assert_cmpstr(qdict_get_try_str(qdict, "implied"), ==, "help.abc");
|
|
|
|
g_assert(!help);
|
|
|
|
qobject_unref(qdict);
|
|
|
|
|
|
|
|
/* "help" with other stuff, without implied key */
|
|
|
|
qdict = keyval_parse("number=42,help,foo=bar", NULL, &help, &error_abort);
|
|
|
|
g_assert_cmpuint(qdict_size(qdict), ==, 2);
|
|
|
|
g_assert_cmpstr(qdict_get_try_str(qdict, "number"), ==, "42");
|
|
|
|
g_assert_cmpstr(qdict_get_try_str(qdict, "foo"), ==, "bar");
|
|
|
|
g_assert(help);
|
|
|
|
qobject_unref(qdict);
|
|
|
|
|
|
|
|
/* "help" with other stuff, with implied key */
|
|
|
|
qdict = keyval_parse("val,help,foo=bar", "implied", &help, &error_abort);
|
|
|
|
g_assert_cmpuint(qdict_size(qdict), ==, 2);
|
|
|
|
g_assert_cmpstr(qdict_get_try_str(qdict, "implied"), ==, "val");
|
|
|
|
g_assert_cmpstr(qdict_get_try_str(qdict, "foo"), ==, "bar");
|
|
|
|
g_assert(help);
|
|
|
|
qobject_unref(qdict);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
}
|
|
|
|
|
keyval: Support lists
Additionally permit non-negative integers as key components. A
dictionary's keys must either be all integers or none. If all keys
are integers, convert the dictionary to a list. The set of keys must
be [0,N].
Examples:
* list.1=goner,list.0=null,list.1=eins,list.2=zwei
is equivalent to JSON [ "null", "eins", "zwei" ]
* a.b.c=1,a.b.0=2
is inconsistent: a.b.c clashes with a.b.0
* list.0=null,list.2=eins,list.2=zwei
has a hole: list.1 is missing
Similar design flaw as for objects: there is no way to denote an empty
list. While interpreting "key absent" as empty list seems natural
(removing a list member from the input string works when there are
multiple ones, so why not when there's just one), it doesn't work:
"key absent" already means "optional list absent", which isn't the
same as "empty list present".
Update the keyval object visitor to use this a.0 syntax in error
messages rather than the usual a[0].
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-25-git-send-email-armbru@redhat.com>
[Off-by-one fix squashed in, as per Kevin's review]
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2017-03-01 00:27:10 +03:00
|
|
|
static void check_list012(QList *qlist)
|
|
|
|
{
|
|
|
|
static const char *expected[] = { "null", "eins", "zwei" };
|
|
|
|
int i;
|
|
|
|
QString *qstr;
|
|
|
|
|
|
|
|
g_assert(qlist);
|
|
|
|
for (i = 0; i < ARRAY_SIZE(expected); i++) {
|
2018-02-24 18:40:29 +03:00
|
|
|
qstr = qobject_to(QString, qlist_pop(qlist));
|
keyval: Support lists
Additionally permit non-negative integers as key components. A
dictionary's keys must either be all integers or none. If all keys
are integers, convert the dictionary to a list. The set of keys must
be [0,N].
Examples:
* list.1=goner,list.0=null,list.1=eins,list.2=zwei
is equivalent to JSON [ "null", "eins", "zwei" ]
* a.b.c=1,a.b.0=2
is inconsistent: a.b.c clashes with a.b.0
* list.0=null,list.2=eins,list.2=zwei
has a hole: list.1 is missing
Similar design flaw as for objects: there is no way to denote an empty
list. While interpreting "key absent" as empty list seems natural
(removing a list member from the input string works when there are
multiple ones, so why not when there's just one), it doesn't work:
"key absent" already means "optional list absent", which isn't the
same as "empty list present".
Update the keyval object visitor to use this a.0 syntax in error
messages rather than the usual a[0].
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-25-git-send-email-armbru@redhat.com>
[Off-by-one fix squashed in, as per Kevin's review]
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2017-03-01 00:27:10 +03:00
|
|
|
g_assert(qstr);
|
|
|
|
g_assert_cmpstr(qstring_get_str(qstr), ==, expected[i]);
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qstr);
|
keyval: Support lists
Additionally permit non-negative integers as key components. A
dictionary's keys must either be all integers or none. If all keys
are integers, convert the dictionary to a list. The set of keys must
be [0,N].
Examples:
* list.1=goner,list.0=null,list.1=eins,list.2=zwei
is equivalent to JSON [ "null", "eins", "zwei" ]
* a.b.c=1,a.b.0=2
is inconsistent: a.b.c clashes with a.b.0
* list.0=null,list.2=eins,list.2=zwei
has a hole: list.1 is missing
Similar design flaw as for objects: there is no way to denote an empty
list. While interpreting "key absent" as empty list seems natural
(removing a list member from the input string works when there are
multiple ones, so why not when there's just one), it doesn't work:
"key absent" already means "optional list absent", which isn't the
same as "empty list present".
Update the keyval object visitor to use this a.0 syntax in error
messages rather than the usual a[0].
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-25-git-send-email-armbru@redhat.com>
[Off-by-one fix squashed in, as per Kevin's review]
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2017-03-01 00:27:10 +03:00
|
|
|
}
|
|
|
|
g_assert(qlist_empty(qlist));
|
|
|
|
}
|
|
|
|
|
|
|
|
static void test_keyval_parse_list(void)
|
|
|
|
{
|
|
|
|
Error *err = NULL;
|
|
|
|
QDict *qdict, *sub_qdict;
|
|
|
|
|
|
|
|
/* Root can't be a list */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("0=1", NULL, NULL, &err);
|
keyval: Support lists
Additionally permit non-negative integers as key components. A
dictionary's keys must either be all integers or none. If all keys
are integers, convert the dictionary to a list. The set of keys must
be [0,N].
Examples:
* list.1=goner,list.0=null,list.1=eins,list.2=zwei
is equivalent to JSON [ "null", "eins", "zwei" ]
* a.b.c=1,a.b.0=2
is inconsistent: a.b.c clashes with a.b.0
* list.0=null,list.2=eins,list.2=zwei
has a hole: list.1 is missing
Similar design flaw as for objects: there is no way to denote an empty
list. While interpreting "key absent" as empty list seems natural
(removing a list member from the input string works when there are
multiple ones, so why not when there's just one), it doesn't work:
"key absent" already means "optional list absent", which isn't the
same as "empty list present".
Update the keyval object visitor to use this a.0 syntax in error
messages rather than the usual a[0].
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-25-git-send-email-armbru@redhat.com>
[Off-by-one fix squashed in, as per Kevin's review]
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2017-03-01 00:27:10 +03:00
|
|
|
error_free_or_abort(&err);
|
|
|
|
g_assert(!qdict);
|
|
|
|
|
|
|
|
/* List elements need not be in order */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("list.0=null,list.2=zwei,list.1=eins", NULL, NULL,
|
|
|
|
&error_abort);
|
keyval: Support lists
Additionally permit non-negative integers as key components. A
dictionary's keys must either be all integers or none. If all keys
are integers, convert the dictionary to a list. The set of keys must
be [0,N].
Examples:
* list.1=goner,list.0=null,list.1=eins,list.2=zwei
is equivalent to JSON [ "null", "eins", "zwei" ]
* a.b.c=1,a.b.0=2
is inconsistent: a.b.c clashes with a.b.0
* list.0=null,list.2=eins,list.2=zwei
has a hole: list.1 is missing
Similar design flaw as for objects: there is no way to denote an empty
list. While interpreting "key absent" as empty list seems natural
(removing a list member from the input string works when there are
multiple ones, so why not when there's just one), it doesn't work:
"key absent" already means "optional list absent", which isn't the
same as "empty list present".
Update the keyval object visitor to use this a.0 syntax in error
messages rather than the usual a[0].
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-25-git-send-email-armbru@redhat.com>
[Off-by-one fix squashed in, as per Kevin's review]
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2017-03-01 00:27:10 +03:00
|
|
|
g_assert_cmpint(qdict_size(qdict), ==, 1);
|
|
|
|
check_list012(qdict_get_qlist(qdict, "list"));
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
keyval: Support lists
Additionally permit non-negative integers as key components. A
dictionary's keys must either be all integers or none. If all keys
are integers, convert the dictionary to a list. The set of keys must
be [0,N].
Examples:
* list.1=goner,list.0=null,list.1=eins,list.2=zwei
is equivalent to JSON [ "null", "eins", "zwei" ]
* a.b.c=1,a.b.0=2
is inconsistent: a.b.c clashes with a.b.0
* list.0=null,list.2=eins,list.2=zwei
has a hole: list.1 is missing
Similar design flaw as for objects: there is no way to denote an empty
list. While interpreting "key absent" as empty list seems natural
(removing a list member from the input string works when there are
multiple ones, so why not when there's just one), it doesn't work:
"key absent" already means "optional list absent", which isn't the
same as "empty list present".
Update the keyval object visitor to use this a.0 syntax in error
messages rather than the usual a[0].
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-25-git-send-email-armbru@redhat.com>
[Off-by-one fix squashed in, as per Kevin's review]
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2017-03-01 00:27:10 +03:00
|
|
|
|
|
|
|
/* Multiple indexes, last one wins */
|
2017-03-20 15:55:44 +03:00
|
|
|
qdict = keyval_parse("list.1=goner,list.0=null,list.01=eins,list.2=zwei",
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
NULL, NULL, &error_abort);
|
keyval: Support lists
Additionally permit non-negative integers as key components. A
dictionary's keys must either be all integers or none. If all keys
are integers, convert the dictionary to a list. The set of keys must
be [0,N].
Examples:
* list.1=goner,list.0=null,list.1=eins,list.2=zwei
is equivalent to JSON [ "null", "eins", "zwei" ]
* a.b.c=1,a.b.0=2
is inconsistent: a.b.c clashes with a.b.0
* list.0=null,list.2=eins,list.2=zwei
has a hole: list.1 is missing
Similar design flaw as for objects: there is no way to denote an empty
list. While interpreting "key absent" as empty list seems natural
(removing a list member from the input string works when there are
multiple ones, so why not when there's just one), it doesn't work:
"key absent" already means "optional list absent", which isn't the
same as "empty list present".
Update the keyval object visitor to use this a.0 syntax in error
messages rather than the usual a[0].
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-25-git-send-email-armbru@redhat.com>
[Off-by-one fix squashed in, as per Kevin's review]
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2017-03-01 00:27:10 +03:00
|
|
|
g_assert_cmpint(qdict_size(qdict), ==, 1);
|
|
|
|
check_list012(qdict_get_qlist(qdict, "list"));
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
keyval: Support lists
Additionally permit non-negative integers as key components. A
dictionary's keys must either be all integers or none. If all keys
are integers, convert the dictionary to a list. The set of keys must
be [0,N].
Examples:
* list.1=goner,list.0=null,list.1=eins,list.2=zwei
is equivalent to JSON [ "null", "eins", "zwei" ]
* a.b.c=1,a.b.0=2
is inconsistent: a.b.c clashes with a.b.0
* list.0=null,list.2=eins,list.2=zwei
has a hole: list.1 is missing
Similar design flaw as for objects: there is no way to denote an empty
list. While interpreting "key absent" as empty list seems natural
(removing a list member from the input string works when there are
multiple ones, so why not when there's just one), it doesn't work:
"key absent" already means "optional list absent", which isn't the
same as "empty list present".
Update the keyval object visitor to use this a.0 syntax in error
messages rather than the usual a[0].
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-25-git-send-email-armbru@redhat.com>
[Off-by-one fix squashed in, as per Kevin's review]
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2017-03-01 00:27:10 +03:00
|
|
|
|
|
|
|
/* List at deeper nesting */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("a.list.1=eins,a.list.00=null,a.list.2=zwei", NULL,
|
keyval: Support lists
Additionally permit non-negative integers as key components. A
dictionary's keys must either be all integers or none. If all keys
are integers, convert the dictionary to a list. The set of keys must
be [0,N].
Examples:
* list.1=goner,list.0=null,list.1=eins,list.2=zwei
is equivalent to JSON [ "null", "eins", "zwei" ]
* a.b.c=1,a.b.0=2
is inconsistent: a.b.c clashes with a.b.0
* list.0=null,list.2=eins,list.2=zwei
has a hole: list.1 is missing
Similar design flaw as for objects: there is no way to denote an empty
list. While interpreting "key absent" as empty list seems natural
(removing a list member from the input string works when there are
multiple ones, so why not when there's just one), it doesn't work:
"key absent" already means "optional list absent", which isn't the
same as "empty list present".
Update the keyval object visitor to use this a.0 syntax in error
messages rather than the usual a[0].
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-25-git-send-email-armbru@redhat.com>
[Off-by-one fix squashed in, as per Kevin's review]
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2017-03-01 00:27:10 +03:00
|
|
|
NULL, &error_abort);
|
|
|
|
g_assert_cmpint(qdict_size(qdict), ==, 1);
|
|
|
|
sub_qdict = qdict_get_qdict(qdict, "a");
|
|
|
|
g_assert_cmpint(qdict_size(sub_qdict), ==, 1);
|
|
|
|
check_list012(qdict_get_qlist(sub_qdict, "list"));
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
keyval: Support lists
Additionally permit non-negative integers as key components. A
dictionary's keys must either be all integers or none. If all keys
are integers, convert the dictionary to a list. The set of keys must
be [0,N].
Examples:
* list.1=goner,list.0=null,list.1=eins,list.2=zwei
is equivalent to JSON [ "null", "eins", "zwei" ]
* a.b.c=1,a.b.0=2
is inconsistent: a.b.c clashes with a.b.0
* list.0=null,list.2=eins,list.2=zwei
has a hole: list.1 is missing
Similar design flaw as for objects: there is no way to denote an empty
list. While interpreting "key absent" as empty list seems natural
(removing a list member from the input string works when there are
multiple ones, so why not when there's just one), it doesn't work:
"key absent" already means "optional list absent", which isn't the
same as "empty list present".
Update the keyval object visitor to use this a.0 syntax in error
messages rather than the usual a[0].
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-25-git-send-email-armbru@redhat.com>
[Off-by-one fix squashed in, as per Kevin's review]
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2017-03-01 00:27:10 +03:00
|
|
|
|
|
|
|
/* Inconsistent dotted keys: both list and dictionary */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("a.b.c=1,a.b.0=2", NULL, NULL, &err);
|
keyval: Support lists
Additionally permit non-negative integers as key components. A
dictionary's keys must either be all integers or none. If all keys
are integers, convert the dictionary to a list. The set of keys must
be [0,N].
Examples:
* list.1=goner,list.0=null,list.1=eins,list.2=zwei
is equivalent to JSON [ "null", "eins", "zwei" ]
* a.b.c=1,a.b.0=2
is inconsistent: a.b.c clashes with a.b.0
* list.0=null,list.2=eins,list.2=zwei
has a hole: list.1 is missing
Similar design flaw as for objects: there is no way to denote an empty
list. While interpreting "key absent" as empty list seems natural
(removing a list member from the input string works when there are
multiple ones, so why not when there's just one), it doesn't work:
"key absent" already means "optional list absent", which isn't the
same as "empty list present".
Update the keyval object visitor to use this a.0 syntax in error
messages rather than the usual a[0].
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-25-git-send-email-armbru@redhat.com>
[Off-by-one fix squashed in, as per Kevin's review]
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2017-03-01 00:27:10 +03:00
|
|
|
error_free_or_abort(&err);
|
|
|
|
g_assert(!qdict);
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("a.0.c=1,a.b.c=2", NULL, NULL, &err);
|
keyval: Support lists
Additionally permit non-negative integers as key components. A
dictionary's keys must either be all integers or none. If all keys
are integers, convert the dictionary to a list. The set of keys must
be [0,N].
Examples:
* list.1=goner,list.0=null,list.1=eins,list.2=zwei
is equivalent to JSON [ "null", "eins", "zwei" ]
* a.b.c=1,a.b.0=2
is inconsistent: a.b.c clashes with a.b.0
* list.0=null,list.2=eins,list.2=zwei
has a hole: list.1 is missing
Similar design flaw as for objects: there is no way to denote an empty
list. While interpreting "key absent" as empty list seems natural
(removing a list member from the input string works when there are
multiple ones, so why not when there's just one), it doesn't work:
"key absent" already means "optional list absent", which isn't the
same as "empty list present".
Update the keyval object visitor to use this a.0 syntax in error
messages rather than the usual a[0].
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-25-git-send-email-armbru@redhat.com>
[Off-by-one fix squashed in, as per Kevin's review]
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2017-03-01 00:27:10 +03:00
|
|
|
error_free_or_abort(&err);
|
|
|
|
g_assert(!qdict);
|
|
|
|
|
|
|
|
/* Missing list indexes */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("list.1=lonely", NULL, NULL, &err);
|
keyval: Support lists
Additionally permit non-negative integers as key components. A
dictionary's keys must either be all integers or none. If all keys
are integers, convert the dictionary to a list. The set of keys must
be [0,N].
Examples:
* list.1=goner,list.0=null,list.1=eins,list.2=zwei
is equivalent to JSON [ "null", "eins", "zwei" ]
* a.b.c=1,a.b.0=2
is inconsistent: a.b.c clashes with a.b.0
* list.0=null,list.2=eins,list.2=zwei
has a hole: list.1 is missing
Similar design flaw as for objects: there is no way to denote an empty
list. While interpreting "key absent" as empty list seems natural
(removing a list member from the input string works when there are
multiple ones, so why not when there's just one), it doesn't work:
"key absent" already means "optional list absent", which isn't the
same as "empty list present".
Update the keyval object visitor to use this a.0 syntax in error
messages rather than the usual a[0].
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-25-git-send-email-armbru@redhat.com>
[Off-by-one fix squashed in, as per Kevin's review]
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2017-03-01 00:27:10 +03:00
|
|
|
error_free_or_abort(&err);
|
|
|
|
g_assert(!qdict);
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("list.0=null,list.2=eins,list.02=zwei", NULL, NULL,
|
|
|
|
&err);
|
keyval: Support lists
Additionally permit non-negative integers as key components. A
dictionary's keys must either be all integers or none. If all keys
are integers, convert the dictionary to a list. The set of keys must
be [0,N].
Examples:
* list.1=goner,list.0=null,list.1=eins,list.2=zwei
is equivalent to JSON [ "null", "eins", "zwei" ]
* a.b.c=1,a.b.0=2
is inconsistent: a.b.c clashes with a.b.0
* list.0=null,list.2=eins,list.2=zwei
has a hole: list.1 is missing
Similar design flaw as for objects: there is no way to denote an empty
list. While interpreting "key absent" as empty list seems natural
(removing a list member from the input string works when there are
multiple ones, so why not when there's just one), it doesn't work:
"key absent" already means "optional list absent", which isn't the
same as "empty list present".
Update the keyval object visitor to use this a.0 syntax in error
messages rather than the usual a[0].
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-25-git-send-email-armbru@redhat.com>
[Off-by-one fix squashed in, as per Kevin's review]
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2017-03-01 00:27:10 +03:00
|
|
|
error_free_or_abort(&err);
|
|
|
|
g_assert(!qdict);
|
|
|
|
}
|
|
|
|
|
2017-03-01 00:26:51 +03:00
|
|
|
static void test_keyval_visit_bool(void)
|
|
|
|
{
|
|
|
|
Error *err = NULL;
|
|
|
|
Visitor *v;
|
|
|
|
QDict *qdict;
|
|
|
|
bool b;
|
|
|
|
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("bool1=on,bool2=off", NULL, NULL, &error_abort);
|
2017-03-01 00:26:51 +03:00
|
|
|
v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
2017-03-01 00:26:51 +03:00
|
|
|
visit_start_struct(v, NULL, NULL, 0, &error_abort);
|
|
|
|
visit_type_bool(v, "bool1", &b, &error_abort);
|
|
|
|
g_assert(b);
|
|
|
|
visit_type_bool(v, "bool2", &b, &error_abort);
|
|
|
|
g_assert(!b);
|
|
|
|
visit_check_struct(v, &error_abort);
|
|
|
|
visit_end_struct(v, NULL);
|
|
|
|
visit_free(v);
|
|
|
|
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("bool1=offer", NULL, NULL, &error_abort);
|
2017-03-01 00:26:51 +03:00
|
|
|
v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
2017-03-01 00:26:51 +03:00
|
|
|
visit_start_struct(v, NULL, NULL, 0, &error_abort);
|
|
|
|
visit_type_bool(v, "bool1", &b, &err);
|
|
|
|
error_free_or_abort(&err);
|
|
|
|
visit_end_struct(v, NULL);
|
|
|
|
visit_free(v);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void test_keyval_visit_number(void)
|
|
|
|
{
|
|
|
|
Error *err = NULL;
|
|
|
|
Visitor *v;
|
|
|
|
QDict *qdict;
|
|
|
|
uint64_t u;
|
|
|
|
|
|
|
|
/* Lower limit zero */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("number1=0", NULL, NULL, &error_abort);
|
2017-03-01 00:26:51 +03:00
|
|
|
v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
2017-03-01 00:26:51 +03:00
|
|
|
visit_start_struct(v, NULL, NULL, 0, &error_abort);
|
|
|
|
visit_type_uint64(v, "number1", &u, &error_abort);
|
|
|
|
g_assert_cmpuint(u, ==, 0);
|
|
|
|
visit_check_struct(v, &error_abort);
|
|
|
|
visit_end_struct(v, NULL);
|
|
|
|
visit_free(v);
|
|
|
|
|
|
|
|
/* Upper limit 2^64-1 */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("number1=18446744073709551615,number2=-1", NULL,
|
2017-03-01 00:26:51 +03:00
|
|
|
NULL, &error_abort);
|
|
|
|
v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
2017-03-01 00:26:51 +03:00
|
|
|
visit_start_struct(v, NULL, NULL, 0, &error_abort);
|
|
|
|
visit_type_uint64(v, "number1", &u, &error_abort);
|
|
|
|
g_assert_cmphex(u, ==, UINT64_MAX);
|
|
|
|
visit_type_uint64(v, "number2", &u, &error_abort);
|
|
|
|
g_assert_cmphex(u, ==, UINT64_MAX);
|
|
|
|
visit_check_struct(v, &error_abort);
|
|
|
|
visit_end_struct(v, NULL);
|
|
|
|
visit_free(v);
|
|
|
|
|
|
|
|
/* Above upper limit */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("number1=18446744073709551616", NULL, NULL,
|
|
|
|
&error_abort);
|
2017-03-01 00:26:51 +03:00
|
|
|
v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
2017-03-01 00:26:51 +03:00
|
|
|
visit_start_struct(v, NULL, NULL, 0, &error_abort);
|
|
|
|
visit_type_uint64(v, "number1", &u, &err);
|
|
|
|
error_free_or_abort(&err);
|
|
|
|
visit_end_struct(v, NULL);
|
|
|
|
visit_free(v);
|
|
|
|
|
|
|
|
/* Below lower limit */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("number1=-18446744073709551616", NULL, NULL,
|
|
|
|
&error_abort);
|
2017-03-01 00:26:51 +03:00
|
|
|
v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
2017-03-01 00:26:51 +03:00
|
|
|
visit_start_struct(v, NULL, NULL, 0, &error_abort);
|
|
|
|
visit_type_uint64(v, "number1", &u, &err);
|
|
|
|
error_free_or_abort(&err);
|
|
|
|
visit_end_struct(v, NULL);
|
|
|
|
visit_free(v);
|
|
|
|
|
|
|
|
/* Hex and octal */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("number1=0x2a,number2=052", NULL, NULL, &error_abort);
|
2017-03-01 00:26:51 +03:00
|
|
|
v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
2017-03-01 00:26:51 +03:00
|
|
|
visit_start_struct(v, NULL, NULL, 0, &error_abort);
|
|
|
|
visit_type_uint64(v, "number1", &u, &error_abort);
|
|
|
|
g_assert_cmpuint(u, ==, 42);
|
|
|
|
visit_type_uint64(v, "number2", &u, &error_abort);
|
|
|
|
g_assert_cmpuint(u, ==, 42);
|
|
|
|
visit_check_struct(v, &error_abort);
|
|
|
|
visit_end_struct(v, NULL);
|
|
|
|
visit_free(v);
|
|
|
|
|
|
|
|
/* Trailing crap */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("number1=3.14,number2=08", NULL, NULL, &error_abort);
|
2017-03-01 00:26:51 +03:00
|
|
|
v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
2017-03-01 00:26:51 +03:00
|
|
|
visit_start_struct(v, NULL, NULL, 0, &error_abort);
|
|
|
|
visit_type_uint64(v, "number1", &u, &err);
|
|
|
|
error_free_or_abort(&err);
|
|
|
|
visit_type_uint64(v, "number2", &u, &err);
|
|
|
|
error_free_or_abort(&err);
|
|
|
|
visit_end_struct(v, NULL);
|
|
|
|
visit_free(v);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void test_keyval_visit_size(void)
|
|
|
|
{
|
|
|
|
Error *err = NULL;
|
|
|
|
Visitor *v;
|
|
|
|
QDict *qdict;
|
|
|
|
uint64_t sz;
|
|
|
|
|
|
|
|
/* Lower limit zero */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("sz1=0", NULL, NULL, &error_abort);
|
2017-03-01 00:26:51 +03:00
|
|
|
v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
2017-03-01 00:26:51 +03:00
|
|
|
visit_start_struct(v, NULL, NULL, 0, &error_abort);
|
|
|
|
visit_type_size(v, "sz1", &sz, &error_abort);
|
|
|
|
g_assert_cmpuint(sz, ==, 0);
|
|
|
|
visit_check_struct(v, &error_abort);
|
|
|
|
visit_end_struct(v, NULL);
|
|
|
|
visit_free(v);
|
|
|
|
|
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
|
|
|
/* Note: full 64 bits of precision */
|
2017-03-01 00:26:51 +03: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
|
|
|
/* Around double limit of precision: 2^53-1, 2^53, 2^53+1 */
|
2017-03-01 00:26:51 +03:00
|
|
|
qdict = keyval_parse("sz1=9007199254740991,"
|
|
|
|
"sz2=9007199254740992,"
|
|
|
|
"sz3=9007199254740993",
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
NULL, NULL, &error_abort);
|
2017-03-01 00:26:51 +03:00
|
|
|
v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
2017-03-01 00:26:51 +03:00
|
|
|
visit_start_struct(v, NULL, NULL, 0, &error_abort);
|
|
|
|
visit_type_size(v, "sz1", &sz, &error_abort);
|
|
|
|
g_assert_cmphex(sz, ==, 0x1fffffffffffff);
|
|
|
|
visit_type_size(v, "sz2", &sz, &error_abort);
|
|
|
|
g_assert_cmphex(sz, ==, 0x20000000000000);
|
|
|
|
visit_type_size(v, "sz3", &sz, &error_abort);
|
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
|
|
|
g_assert_cmphex(sz, ==, 0x20000000000001);
|
2017-03-01 00:26:51 +03:00
|
|
|
visit_check_struct(v, &error_abort);
|
|
|
|
visit_end_struct(v, NULL);
|
|
|
|
visit_free(v);
|
|
|
|
|
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
|
|
|
/* Close to signed integer limit 2^63 */
|
|
|
|
qdict = keyval_parse("sz1=9223372036854775807," /* 7fffffffffffffff */
|
|
|
|
"sz2=9223372036854775808," /* 8000000000000000 */
|
|
|
|
"sz3=9223372036854775809", /* 8000000000000001 */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
NULL, NULL, &error_abort);
|
2017-03-01 00:26:51 +03:00
|
|
|
v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
2017-03-01 00:26:51 +03:00
|
|
|
visit_start_struct(v, NULL, NULL, 0, &error_abort);
|
|
|
|
visit_type_size(v, "sz1", &sz, &error_abort);
|
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
|
|
|
g_assert_cmphex(sz, ==, 0x7fffffffffffffff);
|
2017-03-01 00:26:51 +03:00
|
|
|
visit_type_size(v, "sz2", &sz, &error_abort);
|
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
|
|
|
g_assert_cmphex(sz, ==, 0x8000000000000000);
|
|
|
|
visit_type_size(v, "sz3", &sz, &error_abort);
|
|
|
|
g_assert_cmphex(sz, ==, 0x8000000000000001);
|
2017-03-01 00:26:51 +03:00
|
|
|
visit_check_struct(v, &error_abort);
|
|
|
|
visit_end_struct(v, NULL);
|
|
|
|
visit_free(v);
|
|
|
|
|
|
|
|
/* Close to actual upper limit 0xfffffffffffff800 (53 msbs set) */
|
|
|
|
qdict = keyval_parse("sz1=18446744073709549568," /* fffffffffffff800 */
|
|
|
|
"sz2=18446744073709550591", /* fffffffffffffbff */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
NULL, NULL, &error_abort);
|
2017-03-01 00:26:51 +03:00
|
|
|
v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
2017-03-01 00:26:51 +03:00
|
|
|
visit_start_struct(v, NULL, NULL, 0, &error_abort);
|
|
|
|
visit_type_size(v, "sz1", &sz, &error_abort);
|
|
|
|
g_assert_cmphex(sz, ==, 0xfffffffffffff800);
|
|
|
|
visit_type_size(v, "sz2", &sz, &error_abort);
|
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
|
|
|
g_assert_cmphex(sz, ==, 0xfffffffffffffbff);
|
|
|
|
visit_check_struct(v, &error_abort);
|
|
|
|
visit_end_struct(v, NULL);
|
|
|
|
visit_free(v);
|
|
|
|
|
|
|
|
/* Actual limit 2^64-1*/
|
|
|
|
qdict = keyval_parse("sz1=18446744073709551615", /* ffffffffffffffff */
|
|
|
|
NULL, NULL, &error_abort);
|
|
|
|
v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
|
|
|
|
qobject_unref(qdict);
|
|
|
|
visit_start_struct(v, NULL, NULL, 0, &error_abort);
|
|
|
|
visit_type_size(v, "sz1", &sz, &error_abort);
|
|
|
|
g_assert_cmphex(sz, ==, 0xffffffffffffffff);
|
2017-03-01 00:26:51 +03:00
|
|
|
visit_check_struct(v, &error_abort);
|
|
|
|
visit_end_struct(v, NULL);
|
|
|
|
visit_free(v);
|
|
|
|
|
|
|
|
/* Beyond limits */
|
|
|
|
qdict = keyval_parse("sz1=-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
|
|
|
"sz2=18446744073709551616", /* 2^64 */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
NULL, NULL, &error_abort);
|
2017-03-01 00:26:51 +03:00
|
|
|
v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
2017-03-01 00:26:51 +03:00
|
|
|
visit_start_struct(v, NULL, NULL, 0, &error_abort);
|
|
|
|
visit_type_size(v, "sz1", &sz, &err);
|
|
|
|
error_free_or_abort(&err);
|
|
|
|
visit_type_size(v, "sz2", &sz, &err);
|
|
|
|
error_free_or_abort(&err);
|
|
|
|
visit_end_struct(v, NULL);
|
|
|
|
visit_free(v);
|
|
|
|
|
|
|
|
/* Suffixes */
|
|
|
|
qdict = keyval_parse("sz1=8b,sz2=1.5k,sz3=2M,sz4=0.1G,sz5=16777215T",
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
NULL, NULL, &error_abort);
|
2017-03-01 00:26:51 +03:00
|
|
|
v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
2017-03-01 00:26:51 +03:00
|
|
|
visit_start_struct(v, NULL, NULL, 0, &error_abort);
|
|
|
|
visit_type_size(v, "sz1", &sz, &error_abort);
|
|
|
|
g_assert_cmpuint(sz, ==, 8);
|
|
|
|
visit_type_size(v, "sz2", &sz, &error_abort);
|
|
|
|
g_assert_cmpuint(sz, ==, 1536);
|
|
|
|
visit_type_size(v, "sz3", &sz, &error_abort);
|
2018-06-25 15:41:57 +03:00
|
|
|
g_assert_cmphex(sz, ==, 2 * MiB);
|
2017-03-01 00:26:51 +03:00
|
|
|
visit_type_size(v, "sz4", &sz, &error_abort);
|
2018-06-25 15:41:57 +03:00
|
|
|
g_assert_cmphex(sz, ==, GiB / 10);
|
2017-03-01 00:26:51 +03:00
|
|
|
visit_type_size(v, "sz5", &sz, &error_abort);
|
2018-06-25 15:41:57 +03:00
|
|
|
g_assert_cmphex(sz, ==, 16777215ULL * TiB);
|
2017-03-01 00:26:51 +03:00
|
|
|
visit_check_struct(v, &error_abort);
|
|
|
|
visit_end_struct(v, NULL);
|
|
|
|
visit_free(v);
|
|
|
|
|
|
|
|
/* Beyond limit with suffix */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("sz1=16777216T", NULL, NULL, &error_abort);
|
2017-03-01 00:26:51 +03:00
|
|
|
v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
2017-03-01 00:26:51 +03:00
|
|
|
visit_start_struct(v, NULL, NULL, 0, &error_abort);
|
|
|
|
visit_type_size(v, "sz1", &sz, &err);
|
|
|
|
error_free_or_abort(&err);
|
|
|
|
visit_end_struct(v, NULL);
|
|
|
|
visit_free(v);
|
|
|
|
|
|
|
|
/* Trailing crap */
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("sz1=0Z,sz2=16Gi", NULL, NULL, &error_abort);
|
2017-03-01 00:26:51 +03:00
|
|
|
v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
2017-03-01 00:26:51 +03:00
|
|
|
visit_start_struct(v, NULL, NULL, 0, &error_abort);
|
|
|
|
visit_type_size(v, "sz1", &sz, &err);
|
|
|
|
error_free_or_abort(&err);
|
|
|
|
visit_type_size(v, "sz2", &sz, &err);
|
|
|
|
error_free_or_abort(&err);
|
|
|
|
visit_end_struct(v, NULL);
|
|
|
|
visit_free(v);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void test_keyval_visit_dict(void)
|
|
|
|
{
|
|
|
|
Error *err = NULL;
|
|
|
|
Visitor *v;
|
|
|
|
QDict *qdict;
|
|
|
|
int64_t i;
|
|
|
|
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("a.b.c=1,a.b.c=2,d=3", NULL, NULL, &error_abort);
|
2017-03-01 00:26:51 +03:00
|
|
|
v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
2017-03-01 00:26:51 +03:00
|
|
|
visit_start_struct(v, NULL, NULL, 0, &error_abort);
|
|
|
|
visit_start_struct(v, "a", NULL, 0, &error_abort);
|
|
|
|
visit_start_struct(v, "b", NULL, 0, &error_abort);
|
|
|
|
visit_type_int(v, "c", &i, &error_abort);
|
|
|
|
g_assert_cmpint(i, ==, 2);
|
|
|
|
visit_check_struct(v, &error_abort);
|
|
|
|
visit_end_struct(v, NULL);
|
|
|
|
visit_check_struct(v, &error_abort);
|
|
|
|
visit_end_struct(v, NULL);
|
|
|
|
visit_type_int(v, "d", &i, &error_abort);
|
|
|
|
g_assert_cmpint(i, ==, 3);
|
|
|
|
visit_check_struct(v, &error_abort);
|
|
|
|
visit_end_struct(v, NULL);
|
|
|
|
visit_free(v);
|
|
|
|
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("a.b=", NULL, NULL, &error_abort);
|
2017-03-01 00:26:51 +03:00
|
|
|
v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
2017-03-01 00:26:51 +03:00
|
|
|
visit_start_struct(v, NULL, NULL, 0, &error_abort);
|
|
|
|
visit_start_struct(v, "a", NULL, 0, &error_abort);
|
|
|
|
visit_type_int(v, "c", &i, &err); /* a.c missing */
|
|
|
|
error_free_or_abort(&err);
|
|
|
|
visit_check_struct(v, &err);
|
|
|
|
error_free_or_abort(&err); /* a.b unexpected */
|
|
|
|
visit_end_struct(v, NULL);
|
|
|
|
visit_check_struct(v, &error_abort);
|
|
|
|
visit_end_struct(v, NULL);
|
|
|
|
visit_free(v);
|
|
|
|
}
|
|
|
|
|
keyval: Support lists
Additionally permit non-negative integers as key components. A
dictionary's keys must either be all integers or none. If all keys
are integers, convert the dictionary to a list. The set of keys must
be [0,N].
Examples:
* list.1=goner,list.0=null,list.1=eins,list.2=zwei
is equivalent to JSON [ "null", "eins", "zwei" ]
* a.b.c=1,a.b.0=2
is inconsistent: a.b.c clashes with a.b.0
* list.0=null,list.2=eins,list.2=zwei
has a hole: list.1 is missing
Similar design flaw as for objects: there is no way to denote an empty
list. While interpreting "key absent" as empty list seems natural
(removing a list member from the input string works when there are
multiple ones, so why not when there's just one), it doesn't work:
"key absent" already means "optional list absent", which isn't the
same as "empty list present".
Update the keyval object visitor to use this a.0 syntax in error
messages rather than the usual a[0].
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-25-git-send-email-armbru@redhat.com>
[Off-by-one fix squashed in, as per Kevin's review]
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2017-03-01 00:27:10 +03:00
|
|
|
static void test_keyval_visit_list(void)
|
|
|
|
{
|
|
|
|
Error *err = NULL;
|
|
|
|
Visitor *v;
|
|
|
|
QDict *qdict;
|
|
|
|
char *s;
|
|
|
|
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("a.0=,a.1=I,a.2.0=II", NULL, NULL, &error_abort);
|
keyval: Support lists
Additionally permit non-negative integers as key components. A
dictionary's keys must either be all integers or none. If all keys
are integers, convert the dictionary to a list. The set of keys must
be [0,N].
Examples:
* list.1=goner,list.0=null,list.1=eins,list.2=zwei
is equivalent to JSON [ "null", "eins", "zwei" ]
* a.b.c=1,a.b.0=2
is inconsistent: a.b.c clashes with a.b.0
* list.0=null,list.2=eins,list.2=zwei
has a hole: list.1 is missing
Similar design flaw as for objects: there is no way to denote an empty
list. While interpreting "key absent" as empty list seems natural
(removing a list member from the input string works when there are
multiple ones, so why not when there's just one), it doesn't work:
"key absent" already means "optional list absent", which isn't the
same as "empty list present".
Update the keyval object visitor to use this a.0 syntax in error
messages rather than the usual a[0].
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-25-git-send-email-armbru@redhat.com>
[Off-by-one fix squashed in, as per Kevin's review]
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2017-03-01 00:27:10 +03:00
|
|
|
/* TODO empty list */
|
|
|
|
v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
keyval: Support lists
Additionally permit non-negative integers as key components. A
dictionary's keys must either be all integers or none. If all keys
are integers, convert the dictionary to a list. The set of keys must
be [0,N].
Examples:
* list.1=goner,list.0=null,list.1=eins,list.2=zwei
is equivalent to JSON [ "null", "eins", "zwei" ]
* a.b.c=1,a.b.0=2
is inconsistent: a.b.c clashes with a.b.0
* list.0=null,list.2=eins,list.2=zwei
has a hole: list.1 is missing
Similar design flaw as for objects: there is no way to denote an empty
list. While interpreting "key absent" as empty list seems natural
(removing a list member from the input string works when there are
multiple ones, so why not when there's just one), it doesn't work:
"key absent" already means "optional list absent", which isn't the
same as "empty list present".
Update the keyval object visitor to use this a.0 syntax in error
messages rather than the usual a[0].
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-25-git-send-email-armbru@redhat.com>
[Off-by-one fix squashed in, as per Kevin's review]
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2017-03-01 00:27:10 +03:00
|
|
|
visit_start_struct(v, NULL, NULL, 0, &error_abort);
|
|
|
|
visit_start_list(v, "a", NULL, 0, &error_abort);
|
|
|
|
visit_type_str(v, NULL, &s, &error_abort);
|
|
|
|
g_assert_cmpstr(s, ==, "");
|
|
|
|
g_free(s);
|
|
|
|
visit_type_str(v, NULL, &s, &error_abort);
|
|
|
|
g_assert_cmpstr(s, ==, "I");
|
|
|
|
g_free(s);
|
|
|
|
visit_start_list(v, NULL, NULL, 0, &error_abort);
|
|
|
|
visit_type_str(v, NULL, &s, &error_abort);
|
|
|
|
g_assert_cmpstr(s, ==, "II");
|
|
|
|
g_free(s);
|
|
|
|
visit_check_list(v, &error_abort);
|
|
|
|
visit_end_list(v, NULL);
|
|
|
|
visit_check_list(v, &error_abort);
|
|
|
|
visit_end_list(v, NULL);
|
|
|
|
visit_check_struct(v, &error_abort);
|
|
|
|
visit_end_struct(v, NULL);
|
|
|
|
visit_free(v);
|
|
|
|
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("a.0=,b.0.0=head", NULL, NULL, &error_abort);
|
keyval: Support lists
Additionally permit non-negative integers as key components. A
dictionary's keys must either be all integers or none. If all keys
are integers, convert the dictionary to a list. The set of keys must
be [0,N].
Examples:
* list.1=goner,list.0=null,list.1=eins,list.2=zwei
is equivalent to JSON [ "null", "eins", "zwei" ]
* a.b.c=1,a.b.0=2
is inconsistent: a.b.c clashes with a.b.0
* list.0=null,list.2=eins,list.2=zwei
has a hole: list.1 is missing
Similar design flaw as for objects: there is no way to denote an empty
list. While interpreting "key absent" as empty list seems natural
(removing a list member from the input string works when there are
multiple ones, so why not when there's just one), it doesn't work:
"key absent" already means "optional list absent", which isn't the
same as "empty list present".
Update the keyval object visitor to use this a.0 syntax in error
messages rather than the usual a[0].
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-25-git-send-email-armbru@redhat.com>
[Off-by-one fix squashed in, as per Kevin's review]
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2017-03-01 00:27:10 +03:00
|
|
|
v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
keyval: Support lists
Additionally permit non-negative integers as key components. A
dictionary's keys must either be all integers or none. If all keys
are integers, convert the dictionary to a list. The set of keys must
be [0,N].
Examples:
* list.1=goner,list.0=null,list.1=eins,list.2=zwei
is equivalent to JSON [ "null", "eins", "zwei" ]
* a.b.c=1,a.b.0=2
is inconsistent: a.b.c clashes with a.b.0
* list.0=null,list.2=eins,list.2=zwei
has a hole: list.1 is missing
Similar design flaw as for objects: there is no way to denote an empty
list. While interpreting "key absent" as empty list seems natural
(removing a list member from the input string works when there are
multiple ones, so why not when there's just one), it doesn't work:
"key absent" already means "optional list absent", which isn't the
same as "empty list present".
Update the keyval object visitor to use this a.0 syntax in error
messages rather than the usual a[0].
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-25-git-send-email-armbru@redhat.com>
[Off-by-one fix squashed in, as per Kevin's review]
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2017-03-01 00:27:10 +03:00
|
|
|
visit_start_struct(v, NULL, NULL, 0, &error_abort);
|
|
|
|
visit_start_list(v, "a", NULL, 0, &error_abort);
|
|
|
|
visit_check_list(v, &err); /* a[0] unexpected */
|
|
|
|
error_free_or_abort(&err);
|
|
|
|
visit_end_list(v, NULL);
|
|
|
|
visit_start_list(v, "b", NULL, 0, &error_abort);
|
|
|
|
visit_start_list(v, NULL, NULL, 0, &error_abort);
|
|
|
|
visit_type_str(v, NULL, &s, &error_abort);
|
|
|
|
g_assert_cmpstr(s, ==, "head");
|
|
|
|
g_free(s);
|
|
|
|
visit_type_str(v, NULL, &s, &err); /* b[0][1] missing */
|
|
|
|
error_free_or_abort(&err);
|
|
|
|
visit_end_list(v, NULL);
|
|
|
|
visit_end_list(v, NULL);
|
|
|
|
visit_check_struct(v, &error_abort);
|
|
|
|
visit_end_struct(v, NULL);
|
|
|
|
visit_free(v);
|
|
|
|
}
|
|
|
|
|
2017-03-01 00:26:51 +03:00
|
|
|
static void test_keyval_visit_optional(void)
|
|
|
|
{
|
|
|
|
Visitor *v;
|
|
|
|
QDict *qdict;
|
|
|
|
bool present;
|
|
|
|
int64_t i;
|
|
|
|
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("a.b=1", NULL, NULL, &error_abort);
|
2017-03-01 00:26:51 +03:00
|
|
|
v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
2017-03-01 00:26:51 +03:00
|
|
|
visit_start_struct(v, NULL, NULL, 0, &error_abort);
|
|
|
|
visit_optional(v, "b", &present);
|
|
|
|
g_assert(!present); /* b missing */
|
|
|
|
visit_optional(v, "a", &present);
|
|
|
|
g_assert(present); /* a present */
|
|
|
|
visit_start_struct(v, "a", NULL, 0, &error_abort);
|
|
|
|
visit_optional(v, "b", &present);
|
|
|
|
g_assert(present); /* a.b present */
|
|
|
|
visit_type_int(v, "b", &i, &error_abort);
|
|
|
|
g_assert_cmpint(i, ==, 1);
|
|
|
|
visit_optional(v, "a", &present);
|
|
|
|
g_assert(!present); /* a.a missing */
|
|
|
|
visit_check_struct(v, &error_abort);
|
|
|
|
visit_end_struct(v, NULL);
|
|
|
|
visit_check_struct(v, &error_abort);
|
|
|
|
visit_end_struct(v, NULL);
|
|
|
|
visit_free(v);
|
|
|
|
}
|
|
|
|
|
2017-03-20 15:55:46 +03:00
|
|
|
static void test_keyval_visit_alternate(void)
|
|
|
|
{
|
|
|
|
Error *err = NULL;
|
|
|
|
Visitor *v;
|
|
|
|
QDict *qdict;
|
qapi: Reject alternates that can't work with keyval_parse()
Alternates are sum types like unions, but use the JSON type on the
wire / QType in QObject instead of an explicit tag. That's why we
require alternate members to have distinct QTypes.
The recently introduced keyval_parse() (commit d454dbe) can only
produce string scalars. The qobject_input_visitor_new_keyval() input
visitor mostly hides the difference, so code using a QObject input
visitor doesn't have to care whether its input was parsed from JSON or
KEY=VALUE,... The difference leaks for alternates, as noted in commit
0ee9ae7: a non-string, non-enum scalar alternate value can't currently
be expressed.
In part, this is just our insufficiently sophisticated implementation.
Consider alternate type 'GuestFileWhence'. It has an integer member
and a 'QGASeek' member. The latter is an enumeration with values
'set', 'cur', 'end'. The meaning of b=set, b=cur, b=end, b=0, b=1 and
so forth is perfectly obvious. However, our current implementation
falls apart at run time for b=0, b=1, and so forth. Fixable, but not
today; add a test case and a TODO comment.
Now consider an alternate type with a string and an integer member.
What's the meaning of a=42? Is it the string "42" or the integer 42?
Whichever meaning you pick makes the other inexpressible. This isn't
just an implementation problem, it's fundamental. Our current
implementation will pick string.
So far, we haven't needed such alternates. To make sure we stop and
think before we add one that cannot sanely work with keyval_parse(),
let's require alternate members to have sufficiently distinct
representation in KEY=VALUE,... syntax:
* A string member clashes with any other scalar member
* An enumeration member clashes with bool members when it has value
'on' or 'off'.
* An enumeration member clashes with numeric members when it has a
value that starts with '-', '+', or a decimal digit. This is a
rather lazy approximation of the actual number syntax accepted by
the visitor.
Note that enumeration values starting with '-' and '+' are rejected
elsewhere already, but better safe than sorry.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1495471335-23707-5-git-send-email-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2017-05-22 19:42:15 +03:00
|
|
|
AltStrObj *aso;
|
2017-06-07 19:35:55 +03:00
|
|
|
AltNumEnum *ane;
|
qapi: Reject alternates that can't work with keyval_parse()
Alternates are sum types like unions, but use the JSON type on the
wire / QType in QObject instead of an explicit tag. That's why we
require alternate members to have distinct QTypes.
The recently introduced keyval_parse() (commit d454dbe) can only
produce string scalars. The qobject_input_visitor_new_keyval() input
visitor mostly hides the difference, so code using a QObject input
visitor doesn't have to care whether its input was parsed from JSON or
KEY=VALUE,... The difference leaks for alternates, as noted in commit
0ee9ae7: a non-string, non-enum scalar alternate value can't currently
be expressed.
In part, this is just our insufficiently sophisticated implementation.
Consider alternate type 'GuestFileWhence'. It has an integer member
and a 'QGASeek' member. The latter is an enumeration with values
'set', 'cur', 'end'. The meaning of b=set, b=cur, b=end, b=0, b=1 and
so forth is perfectly obvious. However, our current implementation
falls apart at run time for b=0, b=1, and so forth. Fixable, but not
today; add a test case and a TODO comment.
Now consider an alternate type with a string and an integer member.
What's the meaning of a=42? Is it the string "42" or the integer 42?
Whichever meaning you pick makes the other inexpressible. This isn't
just an implementation problem, it's fundamental. Our current
implementation will pick string.
So far, we haven't needed such alternates. To make sure we stop and
think before we add one that cannot sanely work with keyval_parse(),
let's require alternate members to have sufficiently distinct
representation in KEY=VALUE,... syntax:
* A string member clashes with any other scalar member
* An enumeration member clashes with bool members when it has value
'on' or 'off'.
* An enumeration member clashes with numeric members when it has a
value that starts with '-', '+', or a decimal digit. This is a
rather lazy approximation of the actual number syntax accepted by
the visitor.
Note that enumeration values starting with '-' and '+' are rejected
elsewhere already, but better safe than sorry.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1495471335-23707-5-git-send-email-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2017-05-22 19:42:15 +03:00
|
|
|
AltEnumBool *aeb;
|
2017-03-20 15:55:46 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Can't do scalar alternate variants other than string. You get
|
|
|
|
* the string variant if there is one, else an error.
|
qapi: Reject alternates that can't work with keyval_parse()
Alternates are sum types like unions, but use the JSON type on the
wire / QType in QObject instead of an explicit tag. That's why we
require alternate members to have distinct QTypes.
The recently introduced keyval_parse() (commit d454dbe) can only
produce string scalars. The qobject_input_visitor_new_keyval() input
visitor mostly hides the difference, so code using a QObject input
visitor doesn't have to care whether its input was parsed from JSON or
KEY=VALUE,... The difference leaks for alternates, as noted in commit
0ee9ae7: a non-string, non-enum scalar alternate value can't currently
be expressed.
In part, this is just our insufficiently sophisticated implementation.
Consider alternate type 'GuestFileWhence'. It has an integer member
and a 'QGASeek' member. The latter is an enumeration with values
'set', 'cur', 'end'. The meaning of b=set, b=cur, b=end, b=0, b=1 and
so forth is perfectly obvious. However, our current implementation
falls apart at run time for b=0, b=1, and so forth. Fixable, but not
today; add a test case and a TODO comment.
Now consider an alternate type with a string and an integer member.
What's the meaning of a=42? Is it the string "42" or the integer 42?
Whichever meaning you pick makes the other inexpressible. This isn't
just an implementation problem, it's fundamental. Our current
implementation will pick string.
So far, we haven't needed such alternates. To make sure we stop and
think before we add one that cannot sanely work with keyval_parse(),
let's require alternate members to have sufficiently distinct
representation in KEY=VALUE,... syntax:
* A string member clashes with any other scalar member
* An enumeration member clashes with bool members when it has value
'on' or 'off'.
* An enumeration member clashes with numeric members when it has a
value that starts with '-', '+', or a decimal digit. This is a
rather lazy approximation of the actual number syntax accepted by
the visitor.
Note that enumeration values starting with '-' and '+' are rejected
elsewhere already, but better safe than sorry.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1495471335-23707-5-git-send-email-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2017-05-22 19:42:15 +03:00
|
|
|
* TODO make it work for unambiguous cases like AltEnumBool below
|
2017-03-20 15:55:46 +03:00
|
|
|
*/
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("a=1,b=2,c=on", NULL, NULL, &error_abort);
|
2017-03-20 15:55:46 +03:00
|
|
|
v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
2017-03-20 15:55:46 +03:00
|
|
|
visit_start_struct(v, NULL, NULL, 0, &error_abort);
|
qapi: Reject alternates that can't work with keyval_parse()
Alternates are sum types like unions, but use the JSON type on the
wire / QType in QObject instead of an explicit tag. That's why we
require alternate members to have distinct QTypes.
The recently introduced keyval_parse() (commit d454dbe) can only
produce string scalars. The qobject_input_visitor_new_keyval() input
visitor mostly hides the difference, so code using a QObject input
visitor doesn't have to care whether its input was parsed from JSON or
KEY=VALUE,... The difference leaks for alternates, as noted in commit
0ee9ae7: a non-string, non-enum scalar alternate value can't currently
be expressed.
In part, this is just our insufficiently sophisticated implementation.
Consider alternate type 'GuestFileWhence'. It has an integer member
and a 'QGASeek' member. The latter is an enumeration with values
'set', 'cur', 'end'. The meaning of b=set, b=cur, b=end, b=0, b=1 and
so forth is perfectly obvious. However, our current implementation
falls apart at run time for b=0, b=1, and so forth. Fixable, but not
today; add a test case and a TODO comment.
Now consider an alternate type with a string and an integer member.
What's the meaning of a=42? Is it the string "42" or the integer 42?
Whichever meaning you pick makes the other inexpressible. This isn't
just an implementation problem, it's fundamental. Our current
implementation will pick string.
So far, we haven't needed such alternates. To make sure we stop and
think before we add one that cannot sanely work with keyval_parse(),
let's require alternate members to have sufficiently distinct
representation in KEY=VALUE,... syntax:
* A string member clashes with any other scalar member
* An enumeration member clashes with bool members when it has value
'on' or 'off'.
* An enumeration member clashes with numeric members when it has a
value that starts with '-', '+', or a decimal digit. This is a
rather lazy approximation of the actual number syntax accepted by
the visitor.
Note that enumeration values starting with '-' and '+' are rejected
elsewhere already, but better safe than sorry.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1495471335-23707-5-git-send-email-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2017-05-22 19:42:15 +03:00
|
|
|
visit_type_AltStrObj(v, "a", &aso, &error_abort);
|
|
|
|
g_assert_cmpint(aso->type, ==, QTYPE_QSTRING);
|
|
|
|
g_assert_cmpstr(aso->u.s, ==, "1");
|
|
|
|
qapi_free_AltStrObj(aso);
|
2017-06-07 19:35:55 +03:00
|
|
|
visit_type_AltNumEnum(v, "b", &ane, &err);
|
qapi: Reject alternates that can't work with keyval_parse()
Alternates are sum types like unions, but use the JSON type on the
wire / QType in QObject instead of an explicit tag. That's why we
require alternate members to have distinct QTypes.
The recently introduced keyval_parse() (commit d454dbe) can only
produce string scalars. The qobject_input_visitor_new_keyval() input
visitor mostly hides the difference, so code using a QObject input
visitor doesn't have to care whether its input was parsed from JSON or
KEY=VALUE,... The difference leaks for alternates, as noted in commit
0ee9ae7: a non-string, non-enum scalar alternate value can't currently
be expressed.
In part, this is just our insufficiently sophisticated implementation.
Consider alternate type 'GuestFileWhence'. It has an integer member
and a 'QGASeek' member. The latter is an enumeration with values
'set', 'cur', 'end'. The meaning of b=set, b=cur, b=end, b=0, b=1 and
so forth is perfectly obvious. However, our current implementation
falls apart at run time for b=0, b=1, and so forth. Fixable, but not
today; add a test case and a TODO comment.
Now consider an alternate type with a string and an integer member.
What's the meaning of a=42? Is it the string "42" or the integer 42?
Whichever meaning you pick makes the other inexpressible. This isn't
just an implementation problem, it's fundamental. Our current
implementation will pick string.
So far, we haven't needed such alternates. To make sure we stop and
think before we add one that cannot sanely work with keyval_parse(),
let's require alternate members to have sufficiently distinct
representation in KEY=VALUE,... syntax:
* A string member clashes with any other scalar member
* An enumeration member clashes with bool members when it has value
'on' or 'off'.
* An enumeration member clashes with numeric members when it has a
value that starts with '-', '+', or a decimal digit. This is a
rather lazy approximation of the actual number syntax accepted by
the visitor.
Note that enumeration values starting with '-' and '+' are rejected
elsewhere already, but better safe than sorry.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1495471335-23707-5-git-send-email-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2017-05-22 19:42:15 +03:00
|
|
|
error_free_or_abort(&err);
|
|
|
|
visit_type_AltEnumBool(v, "c", &aeb, &err);
|
2017-03-20 15:55:46 +03:00
|
|
|
error_free_or_abort(&err);
|
|
|
|
visit_end_struct(v, NULL);
|
|
|
|
visit_free(v);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void test_keyval_visit_any(void)
|
|
|
|
{
|
|
|
|
Visitor *v;
|
|
|
|
QDict *qdict;
|
|
|
|
QObject *any;
|
|
|
|
QList *qlist;
|
|
|
|
QString *qstr;
|
|
|
|
|
keyval: Parse help options
This adds a special meaning for 'help' and '?' as options to the keyval
parser. Instead of being an error (because of a missing value) or a
value for an implied key, they now request help, which is a new boolean
output of the parser in addition to the QDict.
A new parameter 'p_help' is added to keyval_parse() that contains on
return whether help was requested. If NULL is passed, requesting help
results in an error and all other cases work like before.
Turning previous error cases into help is a compatible extension. The
behaviour potentially changes for implied keys: They could previously
get 'help' as their value, which is now interpreted as requesting help.
This is not a problem in practice because 'help' and '?' are not a valid
values for the implied key of any option parsed with keyval_parse():
* audiodev: union Audiodev, implied key "driver" is enum AudiodevDriver,
"help" and "?" are not among its values
* display: union DisplayOptions, implied key "type" is enum
DisplayType, "help" and "?" are not among its values
* blockdev: union BlockdevOptions, implied key "driver is enum
BlockdevDriver, "help" and "?" are not among its values
* export: union BlockExport, implied key "type" is enum BlockExportType,
"help" and "?" are not among its values
* monitor: struct MonitorOptions, implied key "mode" is enum MonitorMode,
"help" and "?" are not among its values
* nbd-server: struct NbdServerOptions, no implied key.
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <20201011073505.1185335-5-armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-10-11 10:35:02 +03:00
|
|
|
qdict = keyval_parse("a.0=null,a.1=1", NULL, NULL, &error_abort);
|
2017-03-20 15:55:46 +03:00
|
|
|
v = qobject_input_visitor_new_keyval(QOBJECT(qdict));
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qdict);
|
2017-03-20 15:55:46 +03:00
|
|
|
visit_start_struct(v, NULL, NULL, 0, &error_abort);
|
|
|
|
visit_type_any(v, "a", &any, &error_abort);
|
2018-02-24 18:40:29 +03:00
|
|
|
qlist = qobject_to(QList, any);
|
2017-03-20 15:55:46 +03:00
|
|
|
g_assert(qlist);
|
2018-02-24 18:40:29 +03:00
|
|
|
qstr = qobject_to(QString, qlist_pop(qlist));
|
2017-03-20 15:55:46 +03:00
|
|
|
g_assert_cmpstr(qstring_get_str(qstr), ==, "null");
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qstr);
|
2018-02-24 18:40:29 +03:00
|
|
|
qstr = qobject_to(QString, qlist_pop(qlist));
|
2017-03-20 15:55:46 +03:00
|
|
|
g_assert_cmpstr(qstring_get_str(qstr), ==, "1");
|
|
|
|
g_assert(qlist_empty(qlist));
|
2018-04-19 18:01:43 +03:00
|
|
|
qobject_unref(qstr);
|
|
|
|
qobject_unref(any);
|
2017-03-20 15:55:46 +03:00
|
|
|
visit_check_struct(v, &error_abort);
|
|
|
|
visit_end_struct(v, NULL);
|
|
|
|
visit_free(v);
|
|
|
|
}
|
|
|
|
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
int main(int argc, char *argv[])
|
|
|
|
{
|
|
|
|
g_test_init(&argc, &argv, NULL);
|
|
|
|
g_test_add_func("/keyval/keyval_parse", test_keyval_parse);
|
keyval: Support lists
Additionally permit non-negative integers as key components. A
dictionary's keys must either be all integers or none. If all keys
are integers, convert the dictionary to a list. The set of keys must
be [0,N].
Examples:
* list.1=goner,list.0=null,list.1=eins,list.2=zwei
is equivalent to JSON [ "null", "eins", "zwei" ]
* a.b.c=1,a.b.0=2
is inconsistent: a.b.c clashes with a.b.0
* list.0=null,list.2=eins,list.2=zwei
has a hole: list.1 is missing
Similar design flaw as for objects: there is no way to denote an empty
list. While interpreting "key absent" as empty list seems natural
(removing a list member from the input string works when there are
multiple ones, so why not when there's just one), it doesn't work:
"key absent" already means "optional list absent", which isn't the
same as "empty list present".
Update the keyval object visitor to use this a.0 syntax in error
messages rather than the usual a[0].
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-25-git-send-email-armbru@redhat.com>
[Off-by-one fix squashed in, as per Kevin's review]
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2017-03-01 00:27:10 +03:00
|
|
|
g_test_add_func("/keyval/keyval_parse/list", test_keyval_parse_list);
|
2017-03-01 00:26:51 +03:00
|
|
|
g_test_add_func("/keyval/visit/bool", test_keyval_visit_bool);
|
|
|
|
g_test_add_func("/keyval/visit/number", test_keyval_visit_number);
|
|
|
|
g_test_add_func("/keyval/visit/size", test_keyval_visit_size);
|
|
|
|
g_test_add_func("/keyval/visit/dict", test_keyval_visit_dict);
|
keyval: Support lists
Additionally permit non-negative integers as key components. A
dictionary's keys must either be all integers or none. If all keys
are integers, convert the dictionary to a list. The set of keys must
be [0,N].
Examples:
* list.1=goner,list.0=null,list.1=eins,list.2=zwei
is equivalent to JSON [ "null", "eins", "zwei" ]
* a.b.c=1,a.b.0=2
is inconsistent: a.b.c clashes with a.b.0
* list.0=null,list.2=eins,list.2=zwei
has a hole: list.1 is missing
Similar design flaw as for objects: there is no way to denote an empty
list. While interpreting "key absent" as empty list seems natural
(removing a list member from the input string works when there are
multiple ones, so why not when there's just one), it doesn't work:
"key absent" already means "optional list absent", which isn't the
same as "empty list present".
Update the keyval object visitor to use this a.0 syntax in error
messages rather than the usual a[0].
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-25-git-send-email-armbru@redhat.com>
[Off-by-one fix squashed in, as per Kevin's review]
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
2017-03-01 00:27:10 +03:00
|
|
|
g_test_add_func("/keyval/visit/list", test_keyval_visit_list);
|
2017-03-01 00:26:51 +03:00
|
|
|
g_test_add_func("/keyval/visit/optional", test_keyval_visit_optional);
|
2017-03-20 15:55:46 +03:00
|
|
|
g_test_add_func("/keyval/visit/alternate", test_keyval_visit_alternate);
|
|
|
|
g_test_add_func("/keyval/visit/any", test_keyval_visit_any);
|
keyval: New keyval_parse()
keyval_parse() parses KEY=VALUE,... into a QDict. Works like
qemu_opts_parse(), except:
* Returns a QDict instead of a QemuOpts (d'oh).
* Supports nesting, unlike QemuOpts: a KEY is split into key
fragments at '.' (dotted key convention; the block layer does
something similar on top of QemuOpts). The key fragments are QDict
keys, and the last one's value is updated to VALUE.
* Each key fragment may be up to 127 bytes long. qemu_opts_parse()
limits the entire key to 127 bytes.
* Overlong key fragments are rejected. qemu_opts_parse() silently
truncates them.
* Empty key fragments are rejected. qemu_opts_parse() happily
accepts empty keys.
* It does not store the returned value. qemu_opts_parse() stores it
in the QemuOptsList.
* It does not treat parameter "id" specially. qemu_opts_parse()
ignores all but the first "id", and fails when its value isn't
id_wellformed(), or duplicate (a QemuOpts with the same ID is
already stored). It also screws up when a value contains ",id=".
* Implied value is not supported. qemu_opts_parse() desugars "foo" to
"foo=on", and "nofoo" to "foo=off".
* An implied key's value can't be empty, and can't contain ','.
I intend to grow this into a saner replacement for QemuOpts. It'll
take time, though.
Note: keyval_parse() provides no way to do lists, and its key syntax
is incompatible with the __RFQDN_ prefix convention for downstream
extensions, because it blindly splits at '.', even in __RFQDN_. Both
issues will be addressed later in the series.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Message-Id: <1488317230-26248-4-git-send-email-armbru@redhat.com>
2017-03-01 00:26:49 +03:00
|
|
|
g_test_run();
|
|
|
|
return 0;
|
|
|
|
}
|