Re: bug in simplify_shallow

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

On Sat, Sep 30, 2023 at 01:10:23PM +0200, Ruud H.G. van Tol wrote:
> 
> On 2023-09-29 23:05, Bill Allombert wrote:
> > 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:
> > > > [...] 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.
> 
> Thanks for the changes and fixes!
> 
> (also for not making it return the final length of the list ;) )

Well, there still the issue that

? my(L=List());a=listput(L,5)
? a
%2 = 0

because GP convert void to 0...

> P.S. In paridecl.h, comparing listpop:
> 
>  void    listpop(GEN L, long index);
> 
> shouldn't these now also be void?
> 
>  GEN     listinsert(GEN list, GEN object, long index);
>  GEN     listput(GEN list, GEN object, long index);
> 
> (or does GEN cover that already?)

GP uses listinsert0 and listput0 which returns void.
I have kept the return value for the C functions.

Cheers,
Bill.