[01:45] *** gfldex left
[01:45] *** gfldex joined
[03:21] *** apogee_ntv left
[03:23] *** apogee_ntv joined
[07:57] *** gfldex left
[07:57] *** gfldex joined
[11:07] <lizmat> m: use nqp; nqp::strtocodes("3.99999999999",1,my int32 @a); nqp::splice(@a,nqp::list,1,1); dd @a

[11:07] <evalable6> lizmat, rakudo-moar 6f0f1f5a8: OUTPUT: «(signal SIGSEGV) »

[11:07] <lizmat> m: use nqp; nqp::strtocodes("3.999999",1,my int32 @a); nqp::splice(@a,nqp::list,1,1); dd @a

[11:07] <evalable6> lizmat, rakudo-moar 6f0f1f5a8: OUTPUT: «int32  = array[int32].new(51, 57, 57, 57, 57, 57, 57)␤»

[11:08] <lizmat> m: use nqp; nqp::strtocodes("3.9999999",1,my int32 @a); nqp::splice(@a,nqp::list,1,1); dd @a

[11:08] <evalable6> lizmat, rakudo-moar 6f0f1f5a8: OUTPUT: «(signal SIGSEGV) »

[11:08] <lizmat> this feels like a buffer overflow issue  :-(

[11:09] <lizmat> would be nice if we could fix this for the 2026.05 release  :-)

[11:14] <lizmat> fwiw, it looks like strtocodes is being the naughty one here:

[11:14] <lizmat> m: use nqp; my int32 @a = 51,57,57,57,57,57,57,57,57,57,57,57; nqp::splice(@a,nqp::list,1,1); dd @a   # equivalent without strtocodes

[11:14] <evalable6> lizmat, rakudo-moar 6f0f1f5a8: OUTPUT: «int32  = array[int32].new(51, 57, 57, 57, 57, 57, 57, 57, 57, 57, 57)␤»

[11:27] <lizmat> m: use nqp; my int32 @a = "3.99999999999".ords; nqp::splice(@a,nqp::list,1,1); dd @a   # workaround

[11:27] <evalable6> lizmat, rakudo-moar 6f0f1f5a8: OUTPUT: «int32  = array[int32].new(51, 57, 57, 57, 57, 57, 57, 57, 57, 57, 57, 57)␤»

[14:08] *** harrow left
[14:11] *** harrow joined
[16:06] *** lizmat left
[16:06] *** lizmat_ joined
[17:54] *** lizmat_ left
[17:54] *** lizmat joined
[18:33] *** [Coke] left
[18:34] *** [Coke] joined
[20:34] <lizmat> guess I should make a proper issue for the strtocodes problem

[20:37] *** vrurg joined
[20:39] *** vrurg_ left