Whatever your level with experience with C/XS I think you've tracked down the critical bug. :) More on that in a bit.

You're absolutely right that this data structure should use SVs and not C structs. The very idea of using C structs when an ordinary hash would do is ridiculous! But then it wouldn't illustrate the problem I'm trying to solve.

This technique is being developed for use with Apache Lucy, which will be a large C library with both Perl and Ruby bindings. The "object" member of the struct will actually be a void*, and it could be a Perl object, or a Ruby object, or eventually, something else. (Actually, I don't know exactly whether or how it will work with Ruby -- hopefully it will. :) ) All the Perl-specific C routines need to stay in the XS bindings and cannot be used in the C core. Dereferencing an actual SV and getting at its contents is not an option. However, we need some way of working with native garbage collection, and this is it.

With regards to whether or not storing a pointer is dangerous... it's common practice, even in core modules. You can make DB_File segfault by decrementing the pointer in the tied object! So don't do that. :)

#!/usr/bin/perl
use strict;
use warnings;

use DB_File;
my %hash;
my $tied = tie %hash, 'DB_File', "garbagefile";
$hash{foo} = "bar";
print STDERR $tied->FETCH('foo') . "\n"; 
$$tied--;
print STDERR $tied->FETCH('foo') . "\n"; 

__END__

Outputs:

slothbear:~/perltest marvin$ perl ptrobj_segfault.plx 
bar
Bus error
slothbear:~/perltest marvin$
[download]