On 06/20/2012 03:16 PM, kcrisman wrote:
On Wednesday, June 20, 2012 3:40:24 PM UTC-4, Stephen Montgomery-Smith
wrote:
On 06/20/2012 02:30 PM, kcrisman wrote:
>
>
> On Thursday, April 19, 2012 3:25:44 PM UTC-4, leif wrote:
>
> On 19 Apr., 05:33, Stephen Montgomery-S
On Wednesday, June 20, 2012 3:40:24 PM UTC-4, Stephen Montgomery-Smith
wrote:
>
> On 06/20/2012 02:30 PM, kcrisman wrote:
> >
> >
> > On Thursday, April 19, 2012 3:25:44 PM UTC-4, leif wrote:
> >
> > On 19 Apr., 05:33, Stephen Montgomery-Smith
> > wrote:
> > > I think I have
On 06/20/2012 02:30 PM, kcrisman wrote:
On Thursday, April 19, 2012 3:25:44 PM UTC-4, leif wrote:
On 19 Apr., 05:33, Stephen Montgomery-Smith
wrote:
> I think I have found the problem with sympow. It is nothing to do
with
> elliptic curves. It is simply a malloc/free err
On Thursday, April 19, 2012 3:25:44 PM UTC-4, leif wrote:
>
> On 19 Apr., 05:33, Stephen Montgomery-Smith
> wrote:
> > I think I have found the problem with sympow. It is nothing to do with
> > elliptic curves. It is simply a malloc/free error.
> >
> > In util.c there is a function free_d
On 19 Apr., 05:33, Stephen Montgomery-Smith
wrote:
> I think I have found the problem with sympow. It is nothing to do with
> elliptic curves. It is simply a malloc/free error.
>
> In util.c there is a function free_data, which frees TACKS[0]. TACKS[0]
> is meant to be allocated in disk.c, but
According to the answer to this question
http://www.velocityreviews.com/forums/t713549-check-for-null-before-calling-free.html
it is save since it is part of the c language spec that free(NULL) should do
nothing. So also the debugging replacements Dima is worried about should give
no problem.
On Thursday, 19 April 2012 11:33:36 UTC+8, Stephen Montgomery-Smith wrote:
>
> I think I have found the problem with sympow. It is nothing to do with
> elliptic curves. It is simply a malloc/free error.
>
> In util.c there is a function free_data, which frees TACKS[0]. TACKS[0]
> is meant to
