My advice is almost always the same when someone asks how to do something in XS code: Don't! Do it in Perl code where it is much easier to write, understand, debug, extend, etc. For example:

sub something {
    croak "Usage: ",__PACKAGE__,"::something( $a, $b, $c )"
      unless  3 == @_;
    my $cArray= pack( "d*", @_ );
    _something( $cArray );
}
[download]

along with

void
_something( cArray )
        char *  cArray;
    CODE:
        something( (double *)cArray );
[download]

There are actually ways to look through a Perl array and build this "packed", C-style array of doubles in XS code. They aren't horribly complicated in this specific case, but I don't know what they are because I don't really want to know because I find the Perl solution so much superior.

When writing XS code, I strive to make the XS interface minimal and very C-like and wrap that in Perl code that provides the rich interface that the module user will see.

I find that this approach leads to both more powerful and more efficient modules.

The one exception has been processing of SV buffers since you can't do these things portably in Perl code:

• Determine the current allocated size of an SV's PV buffer
• Grow the SV's PV buffer without changing the SV's value

I've been considering writing an XS module that lets me do these things in Perl and then moving the buffer allocation code of my other XS modules out of XS and back into Perl because the complexity of the buffer allocation code is a problem since XS code is so hard to debug. ):

        - tye (but my friends call me "Tye")