ensure tests are ok for 32bits build#319
Conversation
|
thanks :) |
|
Additional information: I just run a test build in Fedora rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=17684839 Test suite passes on all primary arches: i686, x86_64, ppc64, ppc64le, aarch64 and armv7hl :) |
|
You're no longer consistently testing that 64-bit works on 64-bit systems, which was the point of that test, which tested the code that I added to resolve the problem that 64-bit offsets didn't work, which was the original user issue in #156 and #306. I prefer to avoid testing 64-bits randomly; I appreciate that "most of the time" rand will end up in the upper bit range on a 64-bit system, but that's not going to consistently catch a bug if one is introduced. A more appropriate fix, to me, would be skipping the 64-bit tests based on the value of the PHP_INT_MAX constant. |
|
Or duplicate the test, keeping current one for 32/64 incr, and the new ones for 64bist incr, skipped when PHP_INT_SIZE==4 ? |
|
I was thinking about duplicating the test, too, otherwise it is hidden whether the 64-bits really got exercised. I thought the line about the mt_rand_max() was picking an offset to test, but that was totally unrelated, so, yeah, definitely let's work out some agreeable way to test within the range of available integers. Related: the CAS tokens are always 64-bits, and there is a fallback to strings if the number is larger than the local PHP can handle. Does that many any sense to do here? Or would it just blow up people's code if they suddenly started getting strings back where they expected integers. |
See pr #320 |
switch to pecl sources enable test suite open php-memcached-dev/php-memcached#319 fix test suite for 32bits build
On both i386 and x86_64