speed of mpz_odd_p and lazy allocation

[Marc Glisse]

Hello,

a piece of code that always bothered me:

/* Using "&" rather than "&&" means these can come out branch-free.  Every
    mpz_t has at least one limb allocated, so fetching the low limb is always
    allowed.  */
#define mpz_odd_p(z)   (((z)->_mp_size != 0) & __GMP_CAST (int, (z)->_mp_d[0]))

On the other hand, other optimizations "are omitted to leave open the lazy 
allocation scheme" (ok, this sentence is about the API, not the ABI, but 
we could have an inline mpz_set_ui, not marked as nothrow, without API 
issues). Is this branch in mpz_odd_p so bad, or can I move it back to 
'&&'? (I also want to tweak mpz_get_ui so _mp_d is not dereferenced when 
the size is 0)

Those are first steps towards lazy allocation, but that doesn't mean I am 
going to do the rest now. However, I wanted to mention that there are 
people out faking lazy allocation (yes, they know there are risks). 
Usually they will ensure that allocation really happened before any write, 
but not before reads, and it would be nice if size==0 prevented 
dereferences... (there may be a few more occurences in the code, I'll take 
a look)

-- 
Marc Glisse