From Emmanuel.Thome at inria.fr  Tue Jun  5 19:36:40 2018
From: Emmanuel.Thome at inria.fr (Emmanuel =?utf-8?B?VGhvbcOp?=)
Date: Tue, 5 Jun 2018 21:36:40 +0200
Subject: _ptr and _srcptr types
In-Reply-To: <20180526193816.GA25848@tartare>
References: <20180514080046.GN25124@houblon.loria.fr>
 <9383e5d1fed39bcf79b4b1fab8484640.squirrel@student-web1.dm.unipi.it>
 <20180523223455.GC7474@tartare>
 <nnefhyzwaq.fsf@armitage.lysator.liu.se>
 <20180526193816.GA25848@tartare>
Message-ID: <20180605193640.GD20451@chocolat.lan>

Hi,

Just wondering... where do we go from here ?

E.

On Sat, May 26, 2018 at 09:38:17PM +0200, Emmanuel Thom? wrote:
> On Sat, May 26, 2018 at 09:54:37AM +0200, Niels M?ller wrote:
> > I think I'd like to add something like
> > 
> >   When an array is used as a function argument in C, it is not passed by
> >   value, instead its value is a pointer to the first element. In C
> >   jargon, this is sometimes referred to as the array "decaying" to a
> >   pointer. For GMP types like mpz_t, that means that the function called
> >   gets a pointer to the caller's mpz_t value, which is why no explicit &
> >   operator is needed when passing output arguments. [this is related to
> >   the section Parameter Conventions]
> >   
> >   GMP defines names for these pointer types, e.g., mpz_ptr corresponding
> >   to mpz_t, and mpz_srcptr corresponding to const mpz_t. Most functions
> >   don't need to use these pointer types directly; it works fine to
> >   declare a function using the mpz_t or const mpz_t as the argument
> >   types, the same "pointer decay" happens in the background regardless.
> > 
> >   Occasionally, it is useful to manipulate pointers directly, e.g, to
> >   conditionally swap *references* to a function's inputs without
> >   changing the *values* as seen by the caller, or returning a pointer to
> >   an mpz_t which is part of a larger structure. For these cases, the
> >   pointer types are necessary. And a mpz_ptr can be passed as argument
> >   to any GMP function declared to take an mpz_t argument.
> 
> I wondered indeed whether such an explanation is needed. One may consider
> that it's not the purpose of the Fine Manual to teach the user about C. I
> like your suggested text, though. (typo: "a mpz_ptr" -> "an mpz_ptr").
> 
> > > +equivalent to the following code, which is given for illustratory
> > > +purposes only:
> > > +
> > > + at example
> > > +    typedef some_internal_data_type mpz_t[1];
> > > +    typedef some_internal_data_type * mpz_ptr;
> > > +    typedef const some_internal_data_type * mpz_srcptr;
> > > + at end example
> > 
> > I think it's confusing with a made-up name for the internal types, but
> > actual names for types defined. I'd prefer to either use the actual
> > internal name __mpz_struct instead of some_internal_data_type above, or
> > change to the obviously made up name foo consistently, like
> > 
> >     typedef foo_internal foo_t[1];
> >     typedef foo_internal * foo_ptr;
> >     typedef const foo_internal * foo_srcptr;
> 
> Yes, it's much better (and I have a strong preference for the latter).
> 
> E.
> _______________________________________________
> gmp-devel mailing list
> gmp-devel at gmplib.org
> https://gmplib.org/mailman/listinfo/gmp-devel

From tg at gmplib.org  Thu Jun 28 09:06:09 2018
From: tg at gmplib.org (=?utf-8?Q?Torbj=C3=B6rn?= Granlund)
Date: Thu, 28 Jun 2018 11:06:09 +0200
Subject: New spurious GMP failures caused by Debian upgrade
Message-ID: <86a7rfnuv2.fsf@shell.gmplib.org>

I upgraded the various Debian guest instances over the past week-end.
Now, some 64-bit debian guest systems send spurious SIGKILL to GMP
32-bit ABI test runs.  I not been able to reproduce any of these
failures, nor really tried to understand the trigger conditions.

Because of this bug, we should expect "Table 1. Unexpected failures" at
https://gmplib.org/devel/tm/gmp/date.html to contain some garbage
entries until this (kernel?) bug is fixed.

-- 
Torbj?rn
Please encrypt, key id 0xC8601622