#12858: Bug in sympow
--------------------------------------------+-------------------------------
Reporter: stephen | Owner: rlm
Type: defect | Status: new
Priority: major | Milestone: sage-5.9
Component: memleak | Resolution:
Keywords: sympow | Work issues:
Report Upstream: N/A | Reviewers:
Authors: Stephen Montgomery-Smith | Merged in:
Dependencies: | Stopgaps:
--------------------------------------------+-------------------------------
Comment (by fbissey):
Replying to [comment:6 kcrisman]:
> Since I don't really know C, I don't :) But presumably many other Sage
developers do...
The problem here is that sympow is not even legal C. We had that
conversation a while ago with David Kirkby that sympow was probably by far
the worst piece of code in sage and it couldn't even be entered in "the
obfuscated C contest" since some bits are not even legal C.
The patch looks a bit weird but that's not any weirder than the
surrounding code. And I actually understand the intent and by the look of
it, it is the only case where TACKS[which] is not allocated. The other
solution would be perform some check before deallocation.
But further, TACKS is an array of pointers, shouldn't the pointer be NULL
if not allocated or is it just at the discretion of the compiler, or
possibly a compilation option?
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/12858#comment:7>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
