Re: bug in simplify_shallow

On 2023-09-30 13:27, Bill Allombert wrote:
> 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...

And listpop() acts similar:

? my(L=List([42,43,44])); a=listpop(L); #L
%2 = 2
? a
%3 = 0


Maybe have an enabled compiler-error for such, to avoid surprises.

default(strictvoid, 1)


>> 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.

I presume that is good practice, to prevent breaking something at a 
distance.

-- Ruud