Re: bug in simplify_shallow

You'll see it with valgrind.

From the GP code, I can guess what's happening: the lexical variable L
will be destroyed (gunclone) when we leave the user function scope. But
that user function still returns the return value of listput() which is
the element stored in the list. The latter is a 'clone' (as all list
entries), so supposedly safe. The lexical variable destructor breaks
that asumption.

I don't think the reference count machinery currently in place can
deal with this. Adding a gcopy somewhere should be enough (but slow down
all 'listput' operations...). Don't have time to delve in the C code
right now to confirm this; I'll have a look later if Bill doesn't beat
me to it :-)

Cheers,

    K.B.


* Charles Greathouse [2023-08-26 15:36]:
> I don’t see it on version 2.16.1, df828f1c94.
> 
> On Sat, Aug 26, 2023 at 9:04 AM Ruud H.G. van Tol <[email protected]>
> wrote:
> 
> >
> > ? version()
> > % [2, 15, 4]
> >
> > ? my(L=List()); listput(L,1);
> >    ***   bug in simplify_shallow, type unknown, please report.
> >
> > -- Ruud
> >
> >
> >

    K.B.
-- 
Pr. Karim Belabas, U. Bordeaux, Vice-président en charge du Numérique
Institut de Mathématiques de Bordeaux UMR 5251 - (+33) 05 40 00 29 77
http://www.math.u-bordeaux.fr/~kbelabas/