Re^6: Identify the package a subroutine is being called from

I pulled it right out of SUPER, which is why it had list context correct but was missing the package declaration, as I never thought to put it in a block. Clever trick.

Comment on Re^6: Identify the package a subroutine is being called from

Replies are listed 'Best First'.
Re^7: Identify the package a subroutine is being called from by jettero (Monsignor) on Jun 07, 2008 at 23:36 UTC
I just spent most of my freetime for the day flipping through cop.h, op.c, pp_ctl.c, and for some reason, perly.y. It would appear that blk_sub structs store arguments and CODE refs but never the caller object. So, although you can tease it out of the arguments that happen to be sitting in the stack, you can't really protect against (or even detect) something like unshift @_, "haha, fooled you" in the object that would be returned by calling_object() ... even using XS. I was hoping I could come up with something better in XS, but I couldn't find a way. That's too bad, but it's not the end of the world I suppose. It's an anticlimactic end to my day of hacking though. It's interesting that shift while @_; doesn't ruin the @_ stored in the stack, but unshifting onto it does. Weird, splice @_, 0, 300 doesn't ruin it either, but @_ = () does. I can't explain that. -Paul	[reply]

Replies are listed 'Best First'.

Re^7: Identify the package a subroutine is being called from
by jettero (Monsignor) on Jun 07, 2008 at 23:36 UTC

It would appear that blk_sub structs store arguments and CODE refs but never the caller object. So, although you can tease it out of the arguments that happen to be sitting in the stack, you can't really protect against (or even detect) something like unshift @_, "haha, fooled you" in the object that would be returned by calling_object() ... even using XS. I was hoping I could come up with something better in XS, but I couldn't find a way.

That's too bad, but it's not the end of the world I suppose. It's an anticlimactic end to my day of hacking though.

It's interesting that shift while @_; doesn't ruin the @_ stored in the stack, but unshifting onto it does. Weird, splice @_, 0, 300 doesn't ruin it either, but @_ = () does. I can't explain that.

-Paul

[reply]