01:45 gfldex left, gfldex joined 03:21 apogee_ntv left 03:23 apogee_ntv joined 07:57 gfldex left, gfldex joined
lizmat m: use nqp; nqp::strtocodes("3.99999999999",1,my int32 @a); nqp::splice(@a,nqp::list,1,1); dd @a 11:07
evalable6 (signal SIGSEGV)
lizmat m: use nqp; nqp::strtocodes("3.999999",1,my int32 @a); nqp::splice(@a,nqp::list,1,1); dd @a
evalable6 int32 = array[int32].new(51, 57, 57, 57, 57, 57, 57)
lizmat m: use nqp; nqp::strtocodes("3.9999999",1,my int32 @a); nqp::splice(@a,nqp::list,1,1); dd @a 11:08
evalable6 (signal SIGSEGV)
lizmat this feels like a buffer overflow issue :-(
would be nice if we could fix this for the 2026.05 release :-) 11:09
fwiw, it looks like strtocodes is being the naughty one here: 11:14
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
evalable6 int32 = array[int32].new(51, 57, 57, 57, 57, 57, 57, 57, 57, 57, 57)
lizmat m: use nqp; my int32 @a = "3.99999999999".ords; nqp::splice(@a,nqp::list,1,1); dd @a # workaround 11:27
evalable6 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, lizmat_ joined 17:54 lizmat_ left, lizmat joined 18:33 [Coke] left 18:34 [Coke] joined
lizmat guess I should make a proper issue for the strtocodes problem 20:34
20:37 vrurg joined 20:39 vrurg_ left