where is my magic (XS related)

  • Thread starter Pavel Hlavnicka
  • Start date
P

Pavel Hlavnicka

Hi all,

Abstract: If I assign some magic to a value returned from FIRSTKEY (tie
method) this magic is not present as this value is passed to NEXTKEY.

My XS provides functions for hash 'tie' magic (TIEHASH, FETCH...), all
went fine until I started with FIRSTKEY and NEXTKEY. My extension works
with a complex C++ library and for a hash iteration I need to keep some
library specific iteration key. My idea was to use `~` or `U` magic and
associate it with a key returned from FIRSTKEY and use it later in
NEXTKEY. Like this:

SV *
FIRSTKEY(obj)
SV * obj
PREINIT:
AG_SLOT_ENTRY entry;
char * name;
CODE:
// -------- following really does not matter -------
frame = SV2FRAME(obj);
entry = frame -> GetStartSlot(); //C++ API I use
if (entry) {
name = frame -> getName(entry);
RETVAL = newSVpv((const char*)name, 0);
// ------- here I assign some magic to RETVAL --------
sv_magic(RETVAL, sv_2mortal(newSVuv(PTR2UV(entry))),
PERL_MAGIC_ext, NULL, 0);
} else {
RETVAL = &PL_sv_undef;
}
OUTPUT:
RETVAL


SV*
NEXTKEY(obj, last)
SV * obj;
SV * last;
PREINIT:
AG_SLOT_ENTRY entry;
char * name;
CODE:
frame = SV2FRAME(obj);
MAGIC * magic = mg_find(last, PERL_MAGIC_ext);
// --------- OOPS magic is always null ------------


What's really confusing is that SvTYPE(last) still claims some magic is
present, but there is no magic assigned to this SV at all
(SvMAGIC(last) is NULL)

Using Perl 5.8.5, Fedora 3 vanilla.

Any answer to this long message would be really appreciated!!
Thx

Pavel

P.S.:
I have a XS wrapper round C++ library, my XS is compiled with g++ as
described e.g. here <http://www.johnkeiser.com/perl-xs-c++.html>
Actually I do not suppose this affects my problem.
 
B

Brian McCauley

Pavel said:
Abstract: If I assign some magic to a value returned from FIRSTKEY (tie
method) this magic is not present as this value is passed to NEXTKEY.

Abstract: AFAIK, magic applies to lvalues not to rvalues. When the the
lvalue is resolved to and rvalue, such as when value of the magic SV is
copied to another SV it looses it's magic.

I don't know what would happen if you try to return an value with magic
from a function that's expected to return an rvalue. The behaviour is
probably undefined.

If you want something like magic but which is preserved as the value is
copied from SV to SV you need to go for an object with overload. I've
never done this from XS.
 
J

Joe Schaefer

Pavel Hlavnicka said:
Abstract: If I assign some magic to a value returned from FIRSTKEY
(tie method) this magic is not present as this value is passed to
NEXTKEY.

My XS provides functions for hash 'tie' magic (TIEHASH, FETCH...), all
went fine until I started with FIRSTKEY and NEXTKEY. My extension
works with a complex C++ library and for a hash iteration I need to
keep some library specific iteration key. My idea was to use `~` or
`U` magic and associate it with a key returned from FIRSTKEY and use
it later in NEXTKEY. Like this:

Try adding it to the object instead of the key. MAGIC isn't
preserved across an assignment, which is what perl must do here:
it makes an internal copy of FIRSTKEY's (mortal) RETVAL, to
eventually pass to NEXTKEY as "last".
 
P

Pavel Hlavnicka

Thanks,

you're right it seems. Actually meanwhile I've noticed formerly
overlooked fact that perl allows only single concurrent iteration of the
hash so storing my internal key with an object (not with key) is
sufficient (or even conforming if you want).

What's strange (but understandable) is that my RETVAL with magic is
copied with its type (SvMAGIC returns true) but no magic is retained.
Keeping SV upgraded to PLMG seems to be obsolete. But it really doesn't
hurt much - it was just a bit confusing.

Thank you for your help, I really appreciate it.

Pavel
 
J

Joe Schaefer

Pavel Hlavnicka said:
What's strange (but understandable) is that my RETVAL with magic is
copied with its type (SvMAGIC returns true) but no magic is retained.
^^^^^^^

Do you mean SvMAGICAL(sv), or are you referring to SvTYPE(sv, SVt_PVMG)?
SvMAGICAL probably shouldn't be true, but SvTYPE certainly should be.
Keeping SV upgraded to PLMG seems to be obsolete.

Some internal magics are preserved (taint, v-string), but that's not
really the point. SvTYPE just tells how much room is available in
the sv_any slot (which is tiered via SvUPGRADE). It doesn't say
anything about the sv's actual semantics.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top