Re: bug in simplify_shallow

Bill Allombert <[email protected]>
Newsgroups gmane.comp.mathematics.pari.devel
Message-ID <ZRc8Lv0zNlmZW8+K@seventeen>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.