in reply to [XS] How to detect the TEMP flag

Within XS code, how do I establish that the TEMP flag is there ?

Bah!! ... the TEMP flag doesn't always get set - and it certainly doesn't get set by the XSub. Whether it gets set or not depends upon whether I assign the return of Rmpc_realref() to a variable or not. I rewrote the perl section of my test script, assigning the return value to a variable, and the TEMP flag disappeared altogether.

It looks like I'm unable to bless this object into package Math::MPFR - if I do, I invariably get a segfault when DESTROY() is called. I can't see any way of enabling DESTROY() to distinguish between the 2 "types" of objects.

Cheers,
Rob

Replies are listed 'Best First'.
Re^2: [XS] How to detect the TEMP flag
by ikegami (Patriarch) on Nov 20, 2008 at 07:36 UTC

    I can't see any way of enabling DESTROY() to distinguish between the 2 "types" of objects.

    What two kinds? This TEMP flag business is an XY Problem.

[reply]
[d/l]
      What two kinds?

      For the usual Math::MPFR objects, destruction is conducted as follows: 
      void DESTROY(mpfr_t * p) {
     mpfr_clear(*p);
     Safefree(p);
}

      [download]
      For this slightly different "kind" that I was hoping to introduce, it needs to be: 
      void DESTROY(mpfr_t * p) {
     Safefree(p);
}

      [download]
      This is because, with the latter "kind", there's no dynamically allocated space for mpfr_clear() to clean up - and attempting to do so, simply causes a segfault.

      My main difficulty is that, for both "kinds", the Devel::Peek::Dump() is essentially the same - which leads me to now think that blessing both "kinds" into the same package is a no-go. Initially, I thought I could make use of the TEMP flag - but that's a blind alley that grew out of a poorly designed test script (rather than an XY problem :-)
      If I had realised sooner just what the TEMP flag implied, I would have understood that it had nothing to offer me and my post would have been quite different ... possibly would not have come to fruition.

      Basically, DESTROY() needs to be able to determine whether or not to invoke the mpfr_clear() call - and my problem is that I don't see how it can make that decision, simply because the means to distinguish one "kind" from the other doesn't exist.

      The idea is probably headed for the scrap heap .... the value of what I was thinking of doing has only *limited* value in a perl context, anyway.

      Cheers,
      Rob
[reply]
[d/l]
[select]

        You could bless a 

        struct mpfr_wrapper_t {
   mpfr_t* mpfr;
   BOOL    free_on_destroy;
};

        [download]

        instead.

[reply]
[d/l]

In Section Seekers of Perl Wisdom