speed of mpz_odd_p and lazy allocation

[Niels Möller]

bodrato at mail.dm.unipi.it writes:

> There are places in the code where mp_d[0] is written disregard of
> previous value of size and alloc... (E.g. try $ grep -C2 "PTR *(.)\[0\]
> *=" mpz/*.c )

Pointing to a const limb won't help there, of course. Common scratch
limb (as suggested by Torbjörn) might work.

> Do you mean a sort of realloc-on-write? To protect read-only values?

A was thinking of abort on write, rather. I have seen two use cases that
call for changes to these conventions:

1. Initialization of objects containing mpz_t fields with a single
   memcpy from a template object. Currently, one must also call mpz_init
   for each mpz_t. I imagine Marc's use cases are something similar.

2. Compile time constants. I'd like a way to define compile time
   constant bignums, without using gmp internals.

One could solve (1) by saying that alloc = 0, size = 0 means that
storage should be allcoated at write. _mp_d could point to a scratch
limb, if we want to keep _mp_d[0] writable at all times. And solva part
of (2) by sating that alloc = 0, size != 0 means storage allocated by
the application, and the mpz_t should be treated as read-only by gmp.

Without thinking deeply about it, I think needed handling of alloc = 0
could be done in the unlikely branch of MPZ_REALLOC.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.