On Wed, Mar 11, 2015 at 08:40:46AM -0400, Gabriel L. Somlo wrote: > On Wed, Mar 11, 2015 at 12:59:40PM +0100, Kevin Wolf wrote: > > > > def_value_str exists in the current codebase, and it seems to take > > precedence when a different default is specified by the caller. > > So I've now added .def_value_str fields: > > static QemuOptsList qemu_foo_opts = { > .name = "foo", > .head = QTAILQ_HEAD_INITIALIZER(qemu_foo_opts.head), > .desc = { > { > .name = "name", > .type = QEMU_OPT_STRING, > .def_value_str = "abc", > }, { > .name = "file", > .type = QEMU_OPT_STRING, > .def_value_str = "xyz", > }, > { /* end of list */ } > }, > }; > > but "-foo name,file" still results in qemu_opt_get(opts, "name") > returning "on", rather than "abc". Is that a bug, or am I missing > something, or doing something wrong ?
Specifically, in qemu_opt_get() (in util/qemu-option.c:311) desc->def_value_str is only used if qemu_opt_find() returns NULL, which in my case does NOT happen ("on" is returned instead). That, in turn, probably happens because opts_do_parse() (in util/qemu-options.c:776) assumes that "option without value" is "probably a flag" :) Not sure we'd want to mess with that assumption, but that most likely means I don't get to use .def_value_str the way I thought I could :) Thanks, --Gabriel