Steve Hay said: > muppet wrote: > >>according to the docs for sv_usepvn(), that sounds right. however, >>it's very mind-bending and obfuscated. you're transferring the >>ownership of the memory to the SV, but still cleaning it up what it >>points to yourself. i can't help but ask "why?" >> > I'm not cleaning up what it points to. As I said, the Safefree(foo) was > deliberately commented-out. I'm cleaning up foo->buf because that was > separately allocated and hasn't been "taken over" by the SV.
what i meant was that you're cleaning up the memory pointed to by the object pointed to by foo. that's a hard way to say it. ;-) basically, FooNew() allocates some deep structure, and FooFree() only frees *part* of that structure; this design is confusing. >>by the way, if sv_usepvn() actually reallocates the pointer you passed >>to it, then calling FooFree(foo) is going to be very, very bad. >> > Why? Calling Safefree(foo) is certainly very, very bad, which is why I > wasn't doing it. Trying it to see if it made any difference was just an > act of desperation. I'm quite relieved that it didn't fix anything. it's still very bad, for the reason you pointed out yourself below -- foo doesn't necessarily point to a valid object anymore, because sv_usepvn() may have moved it. we're saying the same thing, i was just in my morning grogginess and said it badly. :-/ my guess is that Safefree() is being safe and not freeing memory it can't find in its pool tables, and thus after foo() has been moved, FooFree() doesn't do anything. you're lucky that dereferencing foo to get foo->buf doesn't cause problems, but i imagine that's something to do with using perl's internal malloc. -- muppet <scott at asofyet dot org>
