bug-gmp
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reading uninitialized memory


From: Kevin Ryde
Subject: Re: Reading uninitialized memory
Date: 27 Jan 2002 07:26:36 +1000
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.5

Andrew Vaught <address@hidden> writes:
>
> On 26 Jan 2002, Kevin Ryde wrote:
> > 
> > Maybe we could have mpz_init (and friends) store a dummy value to the
> > low limb so mpz_get_si (etc) doesn't trigger the checker.  Is there a
> > #define available to say when a checker build is being done?
> 
>    I don't think there is, but there are other, similar products out there
> and I can't see them all defining the same macro.

I had a bit of a nose around, and found checker defines __CHECKER__.
Dunno if that's a documented feature, but it looks pretty sensible.

I'll add some judiciously located dummy stores for the next release.
I think for a start mpz/init.c, mpz/init2.c, mpz/iset.c, mpz/iset_si.c
and mpq/init.c will want them.

>   In order for checker and similar products (purify, Electric Fence)

I think electric fence just checks memory block bounds, rather than
uninitialized reads.  I use it every so often and I think GMP passes.
The GMP --enable-alloca=debug option can be used to expose more
temporary memory blocks to such checking.

>   Given the differing hardware that GMP supports, it seems to me that
> different schemes will be faster on different machines.  Some machines
> will overlap the read, others will just be slowed down by it.

The question is basically whether to add a conditional jump over the
read.  I think on the important processors it's best to avoid
conditionals wherever possible.

It's also worth remembering that the only time the load is not wanted
is when the value in the mpz_t is zero, and I think non-zero is
probably the more common case.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]