mp_ptr and mp_srcptr

[Torbjorn Granlund]

bodrato at mail.dm.unipi.it writes:

  On Thu, January 27, 2011 8:06 am, Paul Zimmermann wrote:
  > on December 17, Vincent Lefèvre asked a question about mp_ptr and
  > mp_srcptr
  
  I do not have a firm opinion on the subject: should mp_ptr and mp_srcptr
  be documented or not?
  
  They are defined and widely used in gmp.h as an handy alias for mp_limb_t*
  (possibly const); we also have mp[zqf]_{,src}ptr defined and used in gmp.h
  with the same naming convention.
  
  On the other side, there are very few basic types defined in
  http://gmplib.org/manual/Nomenclature-and-Types.html
  Moreover all documented types have the "_t" suffix.
  Should we add the "_t" suffix to derived types before documenting them?
  Should we document derived types at all? Or should we remove them from the
  gmp.h header file to avoid polluting the namespace? Or prepend the "__"
  prefix to mark them as private?
  
  I weakly prefer the option: add "_t", then document; but I'm waiting for
  opinions from other users or developers.
  
I too don't have strong opinions.  I suppose I agree with Marco.

Slightly related is whether mp_srcptr is useful at all.  OK, it might
prevent an accidental write to a read-only parameter, but it does not
AFAIK help compilers at all.

A major problem with C's semantics is that a write through a pointer of
type T may modify any object of type T, whether declared const or not.
The const declaration should not be interpreted as a declaration for the
target object, it just serves to say that it may not be modified through
*this* pointer.

We might instead in most places in GMP use a stronger statement; the c99
restrict declarator might be what we need.  (I am not suggesting we
should replace const by restrict; the latter would be used for both read
and write pointers in certain functions.)

-- 
Torbjörn