There is a typedef mechanism that translates standard C types into an appropriate Perl type. I haven't used that myself. I have only written XS code using the Perl types directly. I find it less confusing as to who is doing what in terms of memory management. You will need to use Perl functions to allocate memory if you expect Perl to manage that memory. Of course, Perl will never release any memory back to the O/S, but it will reuse it for its own purposes!
See Inline Cookbook Pod for the greeting() program (shown below). This code works on my machine and discusses memory management. I would use SV types for input to your proc_desc() subroutine and manipulate them appropriately. Perhaps allowing for something more complex than just an 8 bit ASCII string (UTF-8?).
I think you will wind up with 2 input SV's and one output SV:
SV* proc_desc(SV* a, SV* b)
{
....code...
}
use strict;
use warnings;
use Inline 'C';
print greeting('Ingy');
__END__
See https://metacpan.org/dist/Inline-C/view/lib/Inline/C/Cookbook.pod
and the example for "greeting" subroutine.
"I would urge you to stay away from mallocing your own buffer. Just us
+e Perl's built in
memory management. In other words, just create a new Perl string scala
+r. The function
newSVpv does just that. And newSVpvf includes sprintf functionality.
The other problem is getting rid of this new scalar. How will the ref
+count get
decremented after we pass the scalar back? Perl also provides a functi
+on called
sv_2mortal. Mortal variables die when the context goes out of scope. I
+n other words, Perl
will wait until the new scalar gets passed back and then decrement the
+ ref count for you,
thereby making it eligible for garbage collection. See perldoc perlgut
+s.
In this example the sv_2mortal call gets done under the hood by XS, be
+cause we declared
the return type to be SV*."
__C__
SV* greeting(SV* sv_name) {
return (newSVpvf("Hello %s!\n", SvPV(sv_name, PL_na)));
}
