Re: bug in simplify_shallow

[Bill Allombert <Bill.Allombert@math.u-bordeaux.fr>]

On Sun, Aug 27, 2023 at 05:01:07PM +0200, 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.

Indeed there used to be a bug in the compiler that I just fixed
that caused it to fail to take the void context into account in
some case.

Cheers,
Bill