bodr...@mail.dm.unipi.it writes: In general, when supporting zero sizes is an O(1) cost compared to an O(n) or bigger cost of the function, I may agree. On average mpn_zero_p will return after the first branch (on random data, the first limb we check is non-zero). Supporting zero sizes here means doubling the branches on average... That's the kind of reasoning I do, so I must agree with you. :-)
In the whole library, only two calls to mpn_zero_p required support for zero size: https://gmplib.org/repo/gmp/rev/cb5da779cc81 . The other will benefit of the reduced branching. I didn't intend to question your change to mpn_zero_p. I just wanted to clarify my view on mpn and zero sizes in general; the manual text you quoted is not a law by which I intend to abide. :-) Sometimes we have oddities in the library. E.g. mpn_sqrtrem requires that "The most significant limb of {sp, n} must be non-zero.", but supports n=0 (not tested by our test-suite, look at https://gmplib.org/devel/lcov/shell/var/tmp/lcov/gmp/mpn/sqrtrem.c.gcov.html ). That seems weird. mpn/x86_64/fastsse/com.asm does support zero size with an initial test n, n jz L(don) while neither the generic C function for the library ( mpn/generic/com.c ), nor the inlined version in gmp-impl.h does. A mistake, clearly. (I believe assembly code occasionally support zero sizes as a result of their unrolling logic.) -- Torbjörn Please encrypt, key id 0xC8601622 _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org https://gmplib.org/mailman/listinfo/gmp-devel