Paolo Bonzini <pbonz...@redhat.com> writes:
>> Hmm. Parse method doesn't accept output of the print method. Not so
>> nice. Is the "CPU #" decoration essential?
>
> I noticed the same in parse/print string:
>
> static int parse_string(DeviceState *dev, Property *prop, const char *str)
> {
> char **ptr = qdev_get_prop_ptr(dev, prop);
>
> if (*ptr)
> qemu_free(*ptr);
> *ptr = qemu_strdup(str);
> return 0;
> }
>
> static int print_string(DeviceState *dev, Property *prop, char *dest,
> size_t len)
> {
> char **ptr = qdev_get_prop_ptr(dev, prop);
> if (!*ptr)
> return snprintf(dest, len, "<null>");
> return snprintf(dest, len, "\"%s\"", *ptr);
> }
>
> It looks like printing representation is chosen "for the user", not
> for parsing.
Yes, but does that mean we *should* add such decorations?
For me, the print method should be reasonably close to what the parse
method accepts. A bit like Lisp's princ, whose ouput is close, but not
identical to what the reader accepts (for output acceptable to the
reader, use prin1).
As to "for the user":
dev-prop: cpu_env = CPU #0
dev-prop: cpu_env = 0
Both are equally intelligible, in my opinion: obvious if you know what
the property is about, gibberish if you don't. The latter is slightly
easier to parse with simple tools like AWK.
By the way, print_string() should escape double-quote and funny
characters.
