The number is the address[1] of the SV[2], so it's just a question of casting the number into a pointer. To work with it from Perl, you'd need a reference (since it's not necessarily a scalar), so you'd pass the pointer to newRV_inc.
use Test::More tests => 2;
use Inline C => <<'__EOC__';
SV* addr_to_ref(IV addr) {
return newRV_inc((SV*)addr);
}
__EOC__
{
my @a = qw( a b c );
my $ref = \@a;
my $stringified_ref = "$ref";
my $addr = $stringified_ref =~ /0x([0-9a-f]+)/ ? hex($1) : die;
my $ref2 = addr_to_ref($addr);
is(0+$ref, 0+$ref2);
is("@$ref", "@$ref2");
}
That's assuming the SV is still allocated, of course.
- Numerical representation of a pointer.
- Or AV, HV, etc. For the purposes of this post, I consider these to be subtypes of SV.
| [reply]
[d/l]
[select] |
Yeah, I verified it's still allocated using Data::TreeDumper. Will give this a run through and let you know what happens.
LOOKING FOR ADDR ARRAY(0x7fa9bc68be78)
. . .
| | | | | | | | | | | | | | | |- 3 [
+A220] ARRAY(0x7fa9bc68be78)
Nested quite deep as you can see. | [reply]
[d/l] |
Yeah this definitely does what I was wanting. Now to go read up on some perlguts, thanks :)
LOOKING FOR ADDR: ARRAY(0x7faf34532148)
PRINTING REF:
$VAR1 = [
'curItem',
0
];
. . .
| | | | | | | | | | | | | | | |- 3 [
+A220] <187> ARRAY(0x7faf34532148)
The hex conversion throws a portable warning (to warn 32 bit users I guess) if you weren't aware, but that's neither here nor there. | [reply]
[d/l] |
That value is a number that makes sense only while the program runs, and be meaningless after. Run the program twice with the same input, and you will almost certainly never see the same value repeated. If you have the source for the module, you might make a local copy with some diagnostic statements added.
| [reply] |
I realize it only exists while the program runs and the address is never the same on subsequent executions, but I will only ever need to access it immediately while it's still in scope anyway.
I can dig into the module of course and make the error sub more elaborate to check for data structures within an err message using $@, but that wouldn't be the on-the-fly universal fix I'm attempting to get at.
| [reply] |
... I will only ever need to access it immediately while it's still in scope ...
The phrase "... it will error out with a message ..." in the OP suggests that an exception has already been thrown, suggesting in turn that the scope of the object has been exited and the object itself marked for garbage collection. Does the thrown exception carry a copy of the object reference, thereby defeating GC, in addition to a mere stringization thereof? That seems to me to be the only hope you would have of reliably going back to the object in question with the object of dumping it in some useful way.
Give a man a fish: <%-{-{-{-<
| [reply]
[d/l] |
For your universal version, you need to run the program in an environment that has access to the module's symbol table. It would not surprise me to find out such a thing exists; it's far beyond what I know :)
2 minutes with Super Search comes up with Devel::SymDump.
| [reply] |