Re^2: keeping binary data raw (char*)

I was sad to see that Inline::C's documentation doesn't even really hint at what happens if your C function returns a value of type "char*".

In defense of Inline::C:
1) I wonder if Inline::C is under any obligation to document this;
2) There are a number of examples in perldoc Inline::C-Cookbook that *do* deal with newSVpv (usually as a newSVpvf)

Cheers,
Rob

Comment on Re^2: keeping binary data raw (char*) Select or Download Code

Replies are listed 'Best First'.
Re^3: keeping binary data raw (docs) by tye (Sage) on Oct 26, 2007 at 18:25 UTC
I don't get where you think the term "obligation" applies. Based on "obligation" I think you could delete most if not all of the Inline::C documentation. Rather than expecting the vague hints in Inline::C to lead to (a huge jump) ExtUtils/typemap then to perlguts then perlapi then "man strlen" to finally have the (C) '\0' character mentioned, I think it would be more than prudent for Inline::C to document this important and not obvious restriction and skip "typemap", "sv_setpv()", and "strlen()" and just say that a return value of type "char" only works for strings terminated by "\0" (and not containing any non-terminal "\0" characters). I also think an example of `SV` and `return newSVpvn( str, len );` deserves to be in the base manual, not burried in the "cookbook" (or the documentation of the restrictions on "char" should point directly to an appropriate "cookbook" example). It would certainly be better than the example that uses SvPVX(), a macro that should mostly never be used. But, of course, I don't find the author obligated* to do much of anything. - tye	[reply] [d/l] [select]
Re^3: keeping binary data raw (char*) by downer (Monk) on Oct 29, 2007 at 18:59 UTC
newSVpvf works perfectly. i wish i was good enough at C or C++ where i didnt need to make wrappers in perl for stuff like this. perl's I/O is so much more intuitive that either of these two.	[reply]