Looking at your code, my first guess is that the underlying dx_open() is returning -1 and leaving errno set to ENOSYS.
I'll also throw in my lack of respect for T_PTROBJ. In the rare case where you really do want an object to handle your data structure, I feel strongly that you are better off dealing with objects in Perl code rather than putting object manipulation code in XS (where it is hard to get working, hard to debug, hard to maintain, hard to enhance, etc.).
After a very quick scan of your code, it doesn't look like the underlying API is malloc()ing buffers so you won't have to deal with the worst possible problem of XS [getting Perl to deal with data that it didn't malloc()]. So I'd start with the assumption that each struct is going to be filled and used only by the API and so you can treat each as a "black box".
So just pass them around as Perl strings (and pre-extend them to be big enough when appropriate -- either in Perl or in XS). Then when you find a struct that you need to put data into or take data out of (without just using the API to do that), then add functionality for that. Sometimes a simple use of pack() and unpack() is a good idea. But this depends on the struct and what you do with it. Feel free to ask specific questions since I'm being pretty vague. (:
- tye (but my friends call me "Tye")In reply to Re: PerlXS - Function not implemented
by tye
in thread PerlXS - Function not implemented
by cb921
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |