documentation of mpz_ptr and mpz_srcptr

[Torbjorn Granlund]

Marc Glisse <marc.glisse at normalesup.org> writes:

  Hello,
  
  I noticed, trying for once to write code that uses only documented
  interfaces, that mpz_ptr is purposedly undocumented. However, it can
  be useful. I have seen code that could have used it but ended up
  working around this lack, for instance using one more level of
  indirection (mpz_t*). One piece of code was something like:
  
  mpz_t a,b;
  mpz_t* c;
  if(test) c=&a; else c=&b;
  ... code using *c ...
  
  Obviously this works, and there are other ways to make it work, but it
  would be nicer (although it kind of hides the aliasing) if I could
  write:
  
  mpz_t a,b;
  mpz_ptr c;
  if(test) c=a; else c=b;
  ... code using c ...
  
  Am I missing some obvious alternative for mpz_ptr? Otherwise, is there
  really a risk that mpz_ptr will break in a future release?

Probably not.

I think I need stronger arguments for introducing a new type than that
you can omit a measly ampersand in assignments.  :-)
  
  I admit that I also find it clearer to use mpz_ptr and mpz_srcptr
  instead of mpz_t and const mpz_t for the argument and return types of
  a function...

I am not sure I agree.  Using the same type for formal and actual
parameter is probably clearer for most users.  Understanding the
semi-compatibility of mpz_t and mpz_ptr requires more insight into the
wonders of C and C++ than most users have.

-- 
Torbjörn