C doesn't have the concept of "undef". It appears to me that you will have to tell C how undef should be interpreted - whether in this particular context it means a string, int or whatever. In the preceding, the C code would have to know whether undef as the second param means a "missing" string or an int. Maybe for an expected int, undef defaults to a zero? or maybe -1 or maybe 99999? But it appears to me that would have to be within the C code, not in any general mapping of Perl to C? Because undef could mean many different things to C depending upon the context. I don't know how SWIG would help?FuncA("abc",undef,"xyz"); FuncA("abc",3,"xyz"); FuncA("abc","nmo","xyz +"); FuncB(1,undef,3); FuncB(1,"some string",3);
So as my first example post code shows, instead of char* in the C function definition, you need SV*. undef can be passed as an SV value. There is a C function to determine the exact Perl "type" of that SV value (I didn't show that, but there is such a function). My example just showed a simple test for "does this SV structure contain a Perl string or not?". I have seen more complex tests often with complicated || logic. But my first test code shows a simple test for whether the SV contains a valid string within its structure or not and how to deal with the result of that test.
You will have to modify the C function definition to have a pointer to SV (SV*) instead of pointer to character (char*). As my code shows, if that SV doesn't have a valid string, set pointer equal to NULL. If that SV does contain a string, then extract the pointer to that string. When you have a simple char*, this translation is done automatically for you. But undef throws a wrinkle into the works.
I am sure there are some really wild border cases like Perl passing, "123": That is a string but Perl would treat it as an int if used in a math operation.
Yet another thought:
As I think about this, you are copy and pasting this guy's C code into an inline::C Perl section mainly to reduce "start time". You want to call this guy's C code from Perl. But you don't want to modify this guy's code. So instead of calling this guy's code directly, you could write a "wrapper" C function, which you call from Perl. That C wrapper resolves these undef issues and then calls that guy's code. His code is never called with an undef value.
You write:
Your Perl code calls the "my function".unsigned char *my_enctypex_msname(unsigned char *name, SV *ret){ this C code handles undef appropriately and then calls the "copy and paste" enctypex_msname(unsigned char *name, cha +r* ret){} }
In reply to Re^3: Inline::C and NULL pointers
by Marshall
in thread Inline::C and NULL pointers
by markong
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |