On 09/11/20 17:56, Markus Armbruster wrote:
Just like any other QemuOptsList, "machine" may have any number of
QemuOpts. The ones with non-null ID happen to be ignored silently.
Known[*] trap for the unwary.
Are these all singletons?
They are never qemu_opts_find'd with non-NULL id, so I'd say they are.
If lists>merge_lists, you no longer check id_wellformed(). Easy enough
to fix: lift the check before this conditional.
Intentional: we always error with INVALID_PARAMETER, so it's pointless
to check if the id is well-formed.
After the patch:
id fail_if_exists merge_lists | return
non-null don't care true | fail
null don't care true | existing or else new opts
non-null false false | abort
non-null true false | new opts / fail if exist
null don't care false | new opts
Still too many
Discounting the case that aborts as it's not user-controlled (it's
"just" a matter of inspecting qemu_opts_create callers), the rest can be
summarized as:
- merge_lists = false: singleton opts with NULL id; non-NULL id fails
- merge_lists = true: always return new opts; non-NULL id fails if dup
[*] Known to the QemuOpts cognoscenti, whose number could be
embarrasingly close to one.
Maybe not one, but a single hand certainly has a surplus of fingers.
Paolo
