|Subject:||[PATCH] Possible fix for 5.19.4 compatibility|
Yes, we’ve done it again. We’ve broken compatibility with Glib. :-) An implementation detail was leaking through. Passing any scalar to a function should make that scalar itself visible as $_, so foo($x) will cause \$_ to evaluate to the same thing as \$x. This did not work with undef. foo(undef) would make $_ refer to a brand new scalar, rather than the one that undef returns. Glib’s accumulator test in 7.t happens to depend on this bug. Or GType.xs does. In any case &PL_sv_undef is being passed as $_, and then 7.t expects to assign to it. Where &PL_sv_undef is coming from ultimately I don’t know, but the attached patch creates a brand new scalar in GType.xs, just before calling the accumulator callback, just the way perl used to do. All tests pass. I leave it to you to determine what is the best fix.
|Subject:||possible glib fix.txt|
Download possible glib fix.txt
diff -rup Glib-1.301-gy1yG6/GType.xs Glib-1.301-8jML2z/GType.xs --- Glib-1.301-gy1yG6/GType.xs 2013-06-23 09:55:30.000000000 -0700 +++ Glib-1.301-8jML2z/GType.xs 2013-09-08 16:25:48.000000000 -0700 @@ -1091,7 +1091,10 @@ gperl_real_signal_accumulator (GSignalIn PUSHMARK (SP); PUSHs (sv_2mortal (newSVGSignalInvocationHint (ihint))); - SAVED_STACK_PUSHs (sv_2mortal (gperl_sv_from_value (return_accu))); + sv = gperl_sv_from_value (return_accu); + if (sv == &PL_sv_undef) + sv = newSV (0); + SAVED_STACK_PUSHs (sv_2mortal (sv)); SAVED_STACK_PUSHs (sv_2mortal (gperl_sv_from_value (handler_return))); if (callback->data)