bitblit: mp_size_t or size_t?

[Brian Hurt]

The current code uses size_t, which makes it safe for me to do modulos and 
divides instead of shifts and ands.  I am considering shifting the code 
over to using mp_size_t's in the prototype at least, under the assumption 
that if it's provided, it should be used.

The problem is that both bitwise operations (like and) and modulo are 
dicey propositions on negative numbers.  -1 % 4 can be either -1 or 3, 
depending upon the implementation.  -1 & 3 can be either 1 
(sign-magnitude), 2 (one's complement), or 3 (two's complement) depending 
upon how negative numbers are expressed.

Which means, if I move to mp_size_t, I'm going to have to introduce two 
new branchs to catch negative offsets (negative length I can catch by 
changing existing branches- you'll fall into len == 0 case).  This will 
slow the short blits down by about 10% (long blits won't care).

The argument in favor of using mp_size_t is that it puts mp_bitblit into 
more conformance with the rest of the API.  And the slowdown is only with 
using the generic code- on processor specific code where we know the sign 
format, we can correct and it has basically no performance cost.

I'm leaning towards using mp_size_t at the moment, but wanted to give 
people a chance to weigh in.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian