I dont think T_PV is the right one. Doesnt it extract the length based on where the first \0 is? I think he wants T_OPAQUEPTR.
---
$world=~s/war/peace/g
| [reply] |
I understand that PV stands for pointer. But i am new swig and Perl. I kind of understand a little bit but not much at all. The ideal would be that someone write this typemap... I have been stuck on this problem for a week now... I don't understand either why I can't find this on the internet. unsigned char * is very basic in C! Very strange! | [reply] |
No offense my friend but you've been stuck on this problem for so long because you havent been listening to the advice you've been given.
Typemaps are special code snippets that tell XS how to map a C type signature into something that the Perl Engine can use. This means that on one side you have code to turn (unsigned char *) into an SV and the other side how to turn an SV into an (unsigned char *). The way this works is that the C type is paired off with a TYPEMAP name, and that each TYPEMAP name is associated with the two snippets required (going each direction). Each perl comes with a preconfigured list of TYPEMAP names which under normal circumstances will suit MOST use cases. Generally this simply leaves the creation of a localized TYPEMAP entry that does the require structname to typemap name association. Some of the predefined TYPEMAP names are T_PV and T_OPAQUEPTR and similar things.
Getting to the length issue. Perl SV's know how big the PV data (string data for all intents and purposes) are. They know the size of the overall buffer, they know where in the buffer the real string starts, and how much of the buffer is used. Normally when you need to map an arbitrary (char *) ptr into an SV the typemap code for T_PV does the required work for either determining these values by using routines like strlen(), which of course stop at the first null. If the string is going to handle arbitrary data you'll need to map it to an SV using some other technique. Now if the issue is getting an arbitrary string passed from Perl into the C code the T_PV will be sufficient as the SV knows all the right data and the T_PV macro will handle extracting the right bits.
IMO the easiest way to play with all of this is to use Inline::C and inspect its temporary files. Not only that Inline::C has some of the more accessable explanations as to how C/Perl interfacing should work, including detailed explanations of how to set up typemaps (and where to look for further documenation). You may actually be working with SWIG and not Inline::C or XS directly, but underneath its all going to come out pretty similar and use similar techniques. Stop trying to cut your teeth on the least used and least well supported and documentated way to interface C and Perl and get familiar with the easy ones first.
Good luck.
---
$world=~s/war/peace/g
| [reply] |
You shouldn't need to write it, it's already written. Almost nobody uses swig. see perlxs
| [reply] |
It seems to that using T_OPAQUEPTR is going too deep. There must be an easy way... | [reply] |