I'd do something similar but I'd write the "translate Perl data structure into C data structure" code in Perl not in XS. I'd much rather have 6 lines of advanced Perl code than 6 lines of basic XS code (as "basic" as XS code gets). For one, making adjustments to XS code requires compiling and installing a new shared library while limitations or bugs in Perl code can be worked around in so many ways. Just understanding what the XS code is really doing can be quite a challenge while understanding Perl code is something that so many more people are adept at and where you have tons of tools available to aid you (lots of simple ways to "debug" what is going on).

Then there is the fact that dealing with Perl data structures in XS code almost always results in very brittle code (and quite often results in downright buggy code). Your XS code won't handle a tied or overloaded or otherwise magic array of strings while my Perl code will.

sub my_func
{
    my( $string, $int, @strings )= @_;
    my $ptrs= pack "P" x @strings, @strings;
    $ptrs .= pack "LL", 0, 0; # For odd systems with sizeof(IV) < size
+of(void *)
    _my_func( $string, $int, $ptrs );
}

# and

void
_my_func( st­ring, integer, strings )
    const char * string
    int          integer
    char *       strings
CODE:
    my_func( string, integer, (char **)(strings) );
[download]

I find it rather stupid to map "void *" the way the standard typemap does so I used "char *" above.

But the trick that remains is all of the details about lifespan of the data (and other memory allocation traps). The above example works fine so long as the C my_func() just reads the data passed to it and doesn't try to reallocate anything or keep pointers to parts of it to be used at some later date or such. An argument description of just "char ** string" tells very little about those details and those details can completely change how such an argument needs to be handled.