documentation on internals not up to date

[Niels Möller]

"Marco Bodrato" <bodrato at mail.dm.unipi.it> writes:

> ... and it's not just a problem of supporting mpq_denref() we should also
> change some mpq_ functions. If someone does init an mpq_t with:
>   mpz_init (mpq_numref (accumulator));
>   mpz_roinit_n (mpq_denref (accumulator), &const_one, 1);
>
> then a simple, mpq_add (accumulator, accumulator, another_mpq) might fail.

I don't think we should document support for that code. If the user
initializes parts of an mpq with a read-only mpz objects, the user ought
to treat also the mpq object as readonly.

That said, it sounds reasonable to me to use an an unallocated one for
the internal initialization of the denominator. Then we have to support
that the user accesses it and assigned to it like any other mpz object.
But that doesn't mean that we have to promise that mpz objects the user
creates using ro_init behaves in the same friendly way.

E.g., in case we for some reason change the internals to break
assignment to non-zero unallocated objects, we could hack mpq_denref to
do a real allocation if needed (except that the macro is documented to
work on a const mpq_t). Or go back to using an allocated one.

Regards,
/Niels

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