+ /*
+ * If we had an <extra> type, then the object was not as simple, and
+ * we need to restore extra magic now.
+ */
+
+ if (!extra_type)
+ return sv;
+
+ TRACEME(("retrieving magic object for 0x%"UVxf"...", PTR2UV(sv)));
+
+ rv = retrieve(cxt, 0); /* Retrieve <magic object> */
+
+ TRACEME(("restoring the magic object 0x%"UVxf" part of 0x%"UVxf,
+ PTR2UV(rv), PTR2UV(sv)));
+
+ switch (extra_type) {
+ case SHT_TSCALAR:
+ sv_upgrade(sv, SVt_PVMG);
+ break;
+ case SHT_TARRAY:
+ sv_upgrade(sv, SVt_PVAV);
+ AvREAL_off((AV *)sv);
+ break;
+ case SHT_THASH:
+ sv_upgrade(sv, SVt_PVHV);
+ break;
+ default:
+ CROAK(("Forgot to deal with extra type %d", extra_type));
+ break;
+ }
+
+ /*
+ * Adding the magic only now, well after the STORABLE_thaw hook was called
+ * means the hook cannot know it deals with an object whose variable is
+ * tied. But this is happening when retrieving $o in the following case:
+ *
+ * my %h;
+ * tie %h, 'FOO';
+ * my $o = bless \%h, 'BAR';
+ *
+ * The 'BAR' class is NOT the one where %h is tied into. Therefore, as
+ * far as the 'BAR' class is concerned, the fact that %h is not a REAL
+ * hash but a tied one should not matter at all, and remain transparent.
+ * This means the magic must be restored by Storable AFTER the hook is
+ * called.
+ *
+ * That looks very reasonable to me, but then I've come up with this
+ * after a bug report from David Nesting, who was trying to store such
+ * an object and caused Storable to fail. And unfortunately, it was
+ * also the easiest way to retrofit support for blessed ref to tied objects
+ * into the existing design. -- RAM, 17/02/2001
+ */
+
+ sv_magic(sv, rv, mtype, Nullch, 0);
+ SvREFCNT_dec(rv); /* Undo refcnt inc from sv_magic() */
+