Public mpz_ptr and mpz_srcptr

Vincent Lefevre vincent at
Mon Feb 4 14:44:44 CET 2013

On 2013-02-04 14:26:38 +0100, Torbjorn Granlund wrote:
> Vincent Lefevre <vincent at> writes:
>   On 2013-02-04 13:57:16 +0100, Torbjorn Granlund wrote:
>   > I chose to not provide mpz_ptr since I think it would be prone to
>   > errors.  I expect code like this to be created:
>   > 
>   > mpz_ptr
>   > foo (mpz_t a, mpz_t b)
>   > {
>   >   mpz_t c;
>   >   mpz_init (c);
>   >   mpz_add (c, a, b);
>   >   return c;
>   > }
>   This is not specific to GMP: every C coder should know that returning
>   a local variable is incorrect.
> It is?  What is wrong with

Sorry, I sent my mail before re-reading it. I corrected what I meant
in a followup: the *address* of a local variable.

> I don't think it is self-evident that mpz_t is special.

Well, if it weren't special, the beginning of the code could have
never worked (except if mpz_add were always a macro, but I assume
that most users see it as a function).

I agree that the fact that c evaluates to a pointer is a bit hidden,
though, but not completely: the fact that the user writes mpz_ptr
as a return type while the type of c is mpz_t should make him think
about something special.

Anyway, the fact that GCC detects the problem is another security
(users should take care of all warnings). Or do you have an example
that wouldn't trigger a GCC warning?

Vincent Lefèvre <vincent at> - Web: <>
100% accessible validated (X)HTML - Blog: <>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

More information about the gmp-devel mailing list