Interesting! My last post was wrong. You can add ext magic using sv_magic (no vtable) or sv_magicext (with vtable).

Then I guess you missed "The extra fields only have meaning to the associated magic handlers". That means it's entirely up to you what you put in them if you have your own magic.

I wonder if each variables with ext magic has its own virtual table pointer.

I wonder if each variables with ext magic has its own virtual table pointer.

See SvPVMG & SvPVLV at PerlGuts Illustrated. It's probably somewhat out of date due to the 5.9/5.10 changes, but it is still the clearest guide around.

As I say, for my purposes, the SvPVLV and the associated 'x' type magic would pretty much do everything I want, provided I can adjust the LV_ARGS.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP PCW It is as I've been saying!(Audio until 20090817)

If you're ok with messing with it, here's how:

use strict;
use warnings;

use Inline C => <<'__EOI__';

SV* f(SV* sv, I32 pos, I32 len) {
    SV* targ = newSV_type(SVt_PVLV);
    sv_magic(targ, NULL, PERL_MAGIC_substr, NULL, 0);
    LvTYPE(targ)    = 'x';
    LvTARG(targ)    = SvREFCNT_inc_simple(sv);
    LvTARGOFF(targ) = pos;
    LvTARGLEN(targ) = len;
    return targ;
}

__EOI__

use Devel::Peek qw( Dump );

my $x = "abcde";
$_=uc for f($x,1,3);
print("$x\n");        # aBCDe
[download]

If not, just copy the two functions relating to substr in mg.c

I wonder if each variables with ext magic has its own virtual table pointer.

It does! That means that having only one extension type is not as limiting as it seems!

use strict;
use warnings;

use Inline C => <<'__EOI__';


static const char* test1_str = "Hello, ";

static int test1_mg_get(pTHX_ SV *sv, MAGIC *mg) {
    sv_setpvn(sv, test1_str, (STRLEN)strlen(test1_str));
    return 0;
}

static const MGVTBL vtbl_test1 = {
    test1_mg_get,
    NULL,
    NULL,
    NULL,
    NULL
};

SV* get_test1_var() {
    SV* sv = newSV_type(SVt_PVLV);
    sv_magicext(sv, NULL, PERL_MAGIC_ext, &vtbl_test1, NULL, 0);
    return sv;
}



static const char* test2_str = "World!";

static int test2_mg_get(pTHX_ SV *sv, MAGIC *mg) {
    sv_setpvn(sv, test2_str, (STRLEN)strlen(test2_str));
    return 0;
}

static const MGVTBL vtbl_test2 = {
    test2_mg_get,
    NULL,
    NULL,
    NULL,
    NULL
};


SV* get_test2_var() {
    SV* sv = newSV_type(SVt_PVLV);
    sv_magicext(sv, NULL, PERL_MAGIC_ext, &vtbl_test2, NULL, 0);
    return sv;
}

__EOI__

use Devel::Peek qw( Dump );

my $test1 = get_test1_var();
my $test2 = get_test2_var();
print("$test1$test2\n");
[download]

It does! That means that having only one extension type is not as limiting as it seems!

Actually, there are two. There is also uvar magic:

  U  PERL_MAGIC_uvar           vtbl_uvar       Available for use by ex
+tensions
[download]

You can also chain multiple magics. See the description for SvPVMG in Perlguts:

moremagic is a pointer to another MAGIC and is used to form a single linked list of the MAGICs attached to an SV.

For my purposes, it is the lvalueness associated with PVLVs that is of most interest.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP PCW It is as I've been saying!(Audio until 20090817)