Re: segv on stack extending

[Kevin Ryde <user42 zip com au>]

Torsten Schoenfeld <kaffeetisch gmx de> writes:
>
> Yeah, I think this is what's happening.  Unfortunately,
> Glib::Object::get also uses ST in the loop to access the global stack
> pointer directly.

Ah, yep, another where PPCODE unhelpfully pops your args at the start of
the func.  (If you're foolish enough to PUTBACK :-)

> But maybe there's a better way?

What about leaving the names on the stack and replacing progressively
with the results.  (Note the change from PPCODE: to CODE:, the latter
not using a local "SP" at all and not popping anything until you
XSRETURN ... umm, if I'm right about that.)

--- GObject.xs	19 Aug 2008 08:25:23 +1000	1.76
+++ GObject.xs	02 Sep 2008 08:45:57 +1000	
@@ -1190,16 +1190,17 @@
     PREINIT:
 	GValue value = {0,};
 	int i;
-    PPCODE:
+    CODE:
 	PERL_UNUSED_VAR (ix);
 	EXTEND (SP, items-1);
 	for (i = 1; i < items; i++) {
 		char *name = SvPV_nolen (ST (i));
 		init_property_value (object, name, &value);
 		g_object_get_property (object, name, &value);
-		PUSHs(sv_2mortal(_gperl_sv_from_value_internal(&value, TRUE)));
+		ST(i-1) = sv_2mortal(_gperl_sv_from_value_internal(&value, TRUE));
 		g_value_unset (&value);
 	}
+	XSRETURN(items-1);
 
 
 =for apidoc Glib::Object::set


-- 
For a happy marriage a woman needs a man who makes plenty of money, a man
who's attentive in the bedroom, a man who's a good father, and a man who can
do bits of renovation around the house.  Then all she has to worry about is
making sure those four blokes never meet.