Re: [libvirt] [PATCH] virstoragetest: Don't run the test on 32 bit arches

On 04/30/2014 03:47 AM, Peter Krempa wrote: Okay, so I'll definitely prepare two variants of each of the three "parse to unsigned" wrappers - one that allows '-', the other rejects it. Callers can choose which of the two they want. No. The intent is as follows. Parsing to 'long' or 'unsigned long' behaves identically to '[unsigned] long long' on 64-bit platforms and to '[unsigned] int' on 32-bit platforms (really, that just means using strtol/strtoul as-is). Parsing to '[unsigned] long long' behaves identically across platforms (really, just using strtoll/strtoull as-is). Parsing to '[unsigned] int' behaves as though using a 32-bit strtol (on 32-bit platforms, it is easy; on 64-bit platforms we have to do some fudge work). Whether we reject '-' on the unsigned parse is determined by using a new function, so we have three variants (signed, unsigned with sign, unsigned without sign) for three types (int, long, long long). Remember, the POSIX requirements are that strtol() accepts numbers in the range LONG_MIN to LONG_MAX, while strtoul() accepts numbers in the range LONG_MIN to ULONG_MAX (yes, strtoul has a larger range). The interesting boundary cases for int are: Anything between 0 and 2147483647 parses as itself, for all three int variants Anything between 2147483648 and 4294967295 parses as itself for both unsigned int variants, but rejected as out-of-bounds for signed int (this is the behavior required of 32-bit strtol/strtoul) Anything at 4294967296 or larger is rejected as out-of-bounds for all three int variants -0 is parsed as 0 for signed int and unsigned int with sign, and is rejected as out-of-bounds for unsigned int without sign Anything between -1 and -2147483647 parses as itself for signed int, parses as the negation (4294967295 through 2147483649) for unsigned int with sign, and is rejected as out-of-bounds for unsigned int without sign -2147483648 parses as itself for signed int, parses as 2147483648 for unsigned int with sign, and is rejected as out-of-bounds for unsigned int without sign Anything between -2147483649 and -4294967295 is rejected as out of bounds for signed int and unsigned int without sign, and is parsed as the negation (2147483647 through 1) for unsigned int with sign Anything at -4294967296 or beyond is rejected as out-of-bounds for all three int variants That's why I'm working up the test suite before pushing anything; you'll see exactly in the testsuite what I _plan_ to accept, and I may have to tweak the code to match that. Okay, I'm using that as guidance on the patches I'm preparing today. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org