Re: [Qemu-devel] [PATCH 00/16] introduce OptsVisitor, rebase -net/-netdev parsing

[Laszlo Ersek <lersek@redhat.com>]

On 06/06/12 15:03, Laszlo Ersek wrote:

> (b) make all Netdev integer types as strict as possible, remove
>     superfluous checks,

The net init functions all depend on integer optarg values being
non-negative. Originally this is (or should be...) ensured by
parse_option_number() [qemu-option.c] calling strtoull(), and "more
recently" by opts_type_int() in this series.

i. If the opts visitor should be able to parse negative integers
(currently not necessary for net/netdev types), then I have to change
opts_type_int() accordingly. To restore the non-negative invariants, I
must either reintroduce ">= 0" manual checks in the net init funcs
(conflicts with our frugality), or constrain myself to
uint8/uint16/uint32/uint64 field types in the json.

However, the parsed values are often assigned to "int" variables inside
the init functions (and recursively down in further functions), meaning
I'd have to use uint32 for the corresponding field (in order to reach up
to INT_MAX), and then couldn't save myself the case-by-case "<= INT_MAX"
check (in order to stay below).

Summary: if the opts visitor has to parse negative integers, then (b)
above won't spare us the ad-hoc code: int32 will need >=0 checks, uint32
will need <=INT_MAX checks.

ii. If the opts visitor need not parse negative integers, then
opts_type_int() doesn't have to be changed and "int32" field types would
cover most cases (and in fact obviate most of the ad-hoc checks). But
this would mean a limitation in the general case: the "intXXX" field
types would enable only the "upper halves".

Which way should I go?

Thanks,
Laszlo