in reply to Re: Managing C library memory in XS
in thread Managing C library memory in XS

It seems you are not only questioning the hack I proposed using the NV field, but the entire idea of returning C objects to perl as blessed references to SVs holding the pointer value (in the case as an IV), correct? But isn't that a rather common approach? I just checked the JSON::XS library which IMHO is one of the best working CPAN modules. It goes even a step further. It returns an entire native C JSON struct byte-for-byte as a PV string ... and the typemap INPUTs it as the SvPVX pointer. - the (char *) pointer to the Perl string only cast as a JSON*. Isn't that also pointer pass-around and very-dangerously exposing the C-library environment to the Perl environment, ?

Replies are listed 'Best First'.
Re^3: Managing C library memory in XS
by locked_user sundialsvc4 (Abbot) on May 05, 2014 at 18:14 UTC

    Basically, “yes it is.”   And JSON::XS is a wonderful high-performance encoder/decoder for that reason.   But you really aren’t dealing with “multiple persistent internal library-states” and you really aren’t updating anything, either.   Furthermore, that package is intentionally all-about-speed.   The situation suggested to me in the OP appeared to be a little bit different; hence my suggestions for what I thought might work better in the OP’s specific case.   (And they are meant to be nothing more than that.)   There is no “one way to do this sort of thing.”   The best way to “manage C-library memory in XS” really depends altogether upon the library in question.

      Speed is not completely irrelevant for the task at hand. That's antoher reason why I'm reluctant to try copy everything back and forth and like the idea of just blessing a reference to a pointer. Also, the C library actaully does have methods for almost everything, so there's very little API use for actually having wrapper Per blessed-hash objects. to manage stuff.

      But let me ask the question another way:

      What does the Perl interpreter guarantee about dual value objects? Is there any official guarantee of semantics?

      I Mean... Scalar::Util even advertises the use of dualvar() to set both an interger and a string value on a scalar. So some guarantees must be provided.

      If the guarantee is to alway copy and preserve the entire struct SV and struct xpvmg... and in general support multi-valued vars (PV,IV,NV) ...and.. hmm.. NV being the same size as IV, then there should be nothing wrong with the approach.

[reply]

        Not thinking so much of “blessed” anythings.   Instead, thinking of the exchange of (say, a “person”) consisting of a hash-type variable ... which might, say, include a “_personid” element provided by the library and which contains the moniker I spoke of.   Basically, you would be shifting data between C structures and hashes ... a lot ... if you pursued my suggestion.   Which, I will very freely admit, absolutely might not be the right thing for you to do in your case!   (I was wrong once ... lessee, how many years ago was it, now?   Or am I wrong about that ...?)   ;-)

        As far as I know, the dual-value feature is basically there in the name of efficiency, so that you can have '123' and 123 at the same time.   But I am not qualified to answer your question about interpreter guarantees or the lack thereof.

In Section Seekers of Perl Wisdom