Re^2: FFI::Platypus: Replace malloc with GC

«…"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»

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

Replies are listed 'Best First'.
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]