Christian Jaeger <[EMAIL PROTECTED]> writes:
>Hello
>
>(I've just subscribed to this list)
>
>
>I've tried to understand pp_caller,
So have I ;-)
>and copied most code from it into
>an own function (I don't like the overhead of setting up the perl
>stack and call into a perl function just to find out who was the last
>caller..), but it doesn't work as expected. I seems like the way
>pp_caller walks the stack is in the reverse order of how perl's
>caller() function works (i.e. caller(0) is the last index my code is
>going to finds, and the first package my code finds is about the last
>one caller() will return in while (defined($pack=caller($n))){$n++}),
>and apart from being a bit weird I don't know how to find out hen I'm
>at the end of the stack.
>
>
>I don't yet understand how the stack (or stacks, man perlhack tells
>me about the different stacks, but I don't know where they all are
>located in the C code) works, i.e. the curstackinfo with its
>next/prev pointers vs. its cxstack member which seems to be a C array
>(where I don't know how long it is).
>
>(I also don't understand what dopoptosub_at does.)
You are probably going to have to figure those things out, we will try
and help if we can...
If you do please consider submitting a doc patch that describes what
you discover.
>
>PS. the best thing to recognize the caller package would be a pointer
>that doesn't change, so I don't need to verify the whole package name
>but only compare the pointer. Is cop_stash from struct cop (as
>returned by pp_caller) such a reliable pointer?
That at least is easy. Yes cop_stash is what you want. A package is
a name space, that namespace is a hash (i.e. an HV *) i.e.
%main::Package::
Note the trailing ::
These hashes are called 'stashes'. So comparing stash is fine.
>
>PS.2: am I correct assuming that calling an xs function "changes" the
>"current" namespace to the namespace as defined in the .xs file?
No. That is one of things that does not happen when calling an XSUB.
But saddly this was not fool-proof.
package Foo;
somexsub(anotherfunc());
When in somexsub() then current package was _probably_ Foo.
But if anotherfunc() (which was called to create your args) is
a function-in-perl and has been imported - then I _think_ the
"current package" _used_ be left pointing there.
This may have been fixed by now.
A side-effect of the "no" above is of another XSUB calls yours
(via call_sv() say) then the "calling package" is not clearly
defined - do you want the package of the current statement or
the one that provided the calling XSUB?
The other thing to stir into the mix is the effect of eval {}
which complicates the stack stuff...
>Is
>there any way to easily get at the current namespace (i.e. the
>__PACKAGE__ value) from xs? If the current namespace is not changed
>then this value would already be what I'm looking for..
PL_curcop is a pointer to the current context-op.
So you _may_ be able to get away with PL_curcop->cop_stash
but you need to try it under various "strange" cases and check
you always get what you expect.
