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
