Christian Jaeger <[EMAIL PROTECTED]> writes:
>At 10:56 Uhr +0100 21.08.2003, Nick Ing-Simmons wrote:
>>These hashes are called 'stashes'. So comparing stash is fine.
>
>Sorry, I copy-pasted the wrong entry, I've meant cop_stashpv.
>pp_caller returns CopSTASHPV(), and this macro accesses cop_stashpv
>if USE_ITHREADS is true, and HvNAME(CopSTASH(x)) otherwise. In the
>name of portability I probably have to be content with the resulting
>char*. Now I'm wondering if this one is "stable" as well.
Maybe. It may not be constant across threads, I can't remember
which things are shared and which are duplicated when you "clone"
a new thread.
>>
>>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?
>
>I'm not sure what you mean with "the [statement] that provided the
>calling XSUB".
Suppose in some .xs file I have
MODULE = Bar PACKAGE = Bar
DoCall(SV *hvref)
CODE:
{
SV **svp = hv_fetch((HV *)SvRV(hvref),"d",1,0); // will call your FETCH
}
And then over in perl:
package Foo;
Bar::DoCall(\%oneofYourHahes);
Should you be checking Bar (the notional package name of XSUB accessing
the hash) or Foo (the "current package")?
>
>Class::PredefinedFields::Tie::{FETCH,STORE,..} must know that
>$obj->{d}=1 is in package main.
>
>(And Class::PredefinedFields::import must know that use
>Class::PredefinedFields is in package Foo, but I'm not yet sure I'll
>implement the import function in XS.)
>
>>The other thing to stir into the mix is the effect of eval {}
>>which complicates the stack stuff...
>
>I've noticed the several cx_type's. But it shouldn't matter since I
>simply want the *last* statement that's calling me.
If you get into stack tracing though the eval {} still gets you
eval { $obj->{d} = 1 };
You _immediate_ "caller" is the eval.
An presumably user put it there so he can "catch" your croak-s ...
>>
>>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.
>
>Coool, works (on 5.6.1)! Even simpler than I expected :)
>(Well since cop_stash does not exist when compiling with ithreads,
>maybe I should use CopSTASHPV(PL_curcop).)
Likely.
>I'll see if it will be enough in all cases.
>
>Thanks,
>Christian.
