in reply to Re^3: FFI::Platypus: Replace malloc with GC_MALLOC?
in thread FFI::Platypus: Replace malloc with GC_MALLOC?

And there's plenty of reason to want to learn how to perform cleanup.

Frankly, I can't think of a worse way of doing it than in an END{} block - especially if it's one that actually allocates more memory.

There's no reason to believe it would be the same.

You haven't checked ??
You tell someone to do END { string_reverse( undef ); }, but you don't know if it will work as intended ....
Update: I finally got FFI::Platypus working and was able to verify for myself that, with FFI::Platypus, "undef" does, indeed, get received as "NULL". The END{} block is therefore working as intended.

Finally, you're incorrect assuming that the termination of a Perl interpreter only occurs when the program is unloaded (i.e. when process exits, execs, etc).

I didn't even know that I had made such an assumption. Thank you for that information. (I've learned so much about myself from you, over the years ;-)
I believe that whenever an END{} block is executed, it is immediately followed by a cleanup that would have freed any memory that the END{} block frees.
I don't see any point in using an END{} block to do something that would have happened next anyway.

Of course, it's a different matter if it turns out that there are instances where an END{} block will be executed, but without the following cleanup.
In such a case, I agree that the END{} block approach is better than nothing, but it still defers the freeing of memory to much later than a half-decent programmer would allow.
The best way that I know of is to have the function that assigns the memory, free the memory. But we haven't even touched upon that in this thread.

Cheers,
Rob