Re: bug in simplify_shallow

["Ruud H.G. van Tol" <rvtol@isolution.nl>]

On 2023-08-27 17:01, Ruud H.G. van Tol wrote:
> On 2023-08-27 16:13, Karim Belabas wrote:
> > * Ruud H.G. van Tol [2023-08-27 15:42]:
> > > On 2023-08-27 14:58, Bill Allombert wrote:
> > > > [...]to be honest I did not remember that listput returned x and it is
> > > > not explicitly documented
> > > ? ??listput
> > > listput( list,x,{n}):
> > > [...] The function returns the inserted element.
> > What "the inserted element" means is ambiguous in the context of PARI's
> > memory model. What the implementation does is return a direct pointer to
> > the new list entry, that inserted element being a clone of the input x.
> >
> > What Bill and I suggested was to return "a copy of the inserted element"
> > instead. I don't really see a scenario where this would break
> > compatibility ... except this would make insertion about twice slower,
> > even in cases where the returned value is ignored.
>
> Yes, so I wondered if the "void calling context" is decidable at 
> compile-time,
> such that any new overhead can be avoided where feasible.

Alternatively, postpone the free's until end-of-scope.

-- Ruud