Re: FFI::Platypus: Replace malloc with GC

What I enjoy about Perl and C++ (and don't enjoy about Java ;-) is Deterministic Destructors. Of course, a drawback to Deterministic Destructors that Java-like tracing GCs solve is the dreaded Circular Reference problem.

I've not answered your question because I don't understand it (though I added it my Deterministic Destructor References :). Perhaps you could give us some background about the "why" behind your question. What specific problem are you trying to solve?

Comment on Re: FFI::Platypus: Replace malloc with GC_MALLOC?

Replies are listed 'Best First'.
Re^2: FFI::Platypus: Replace malloc with GC_MALLOC? by karlgoethebier (Abbot) on Dec 12, 2022 at 04:15 UTC
«…"why"…» The background is curiosity and boredom - and I'm just trying to improve my poor C knowledge. It seems quite unusual to me that a function has to be called twice to behave correctly - that is, to free the memory in this case. Regards, Karl «The Crux of the Biscuit is the Apostrophe»	[reply]
Re^3: FFI::Platypus: Replace malloc with GC_MALLOC? by eyepopslikeamosquito (Archbishop) on Dec 12, 2022 at 08:01 UTC
I'm just trying to improve my poor C knowledge Be careful what you wish for. :) I'm not sure studying large and complex C code bases is a good way to learn C. I started by reading The C Programming Language, aka K&R, from cover to cover. Having slaved over many huge C code bases over the years, I can assure you they all rely heavily on static and dynamic code analysis tools to keep the code clean (e.g. Coverity, Valgrind, AddressSanitizer and many more). P5P is no different, as indicated by the EXTERNAL TOOLS FOR DEBUGGING PERL section at perlhack. So, if you want to become a serious C coder, you must master these tools.	[reply]
Re^3: FFI::Platypus: Replace malloc with GC_MALLOC? by ikegami (Patriarch) on Dec 13, 2022 at 13:57 UTC
I'm just trying to improve my poor C knowledge. You picked something that's probably a bit too advanced for that. It involves not just C, but knowledge of FFI and of Perl internals as well, both of which are complex systems. Is [replacing malloc with GC_MALLOC] recommended or will it cause problems in the future not yet imaginable now? The answer to the question depends on whether FFI or Perl can free the returned buffer. I think the `const` in the return type tells FFI to copy the string and avoid freeing it. If so, then yes, you could use a different allocator. I'm guessing that because the example would have problem as-is if FFI or Perl could free the buffer.	[reply] [d/l]