Hi, I'm the wrong Alex (and I'm probably wrong), but I would think that memory allocated by malloc() isn't managed by the GC. IDK if you can install finalizers or something similar.
Best Regards, The Other Professor ^W Alex. Am 13. November 2020 16:30:01 MEZ schrieb C K Kashyap <ckkash...@gmail.com>: >Thanks Alex, >Is the allocated memory purged by the GC in your example? If not, would >it >be straightforward to plug it in a manner that the GC handles the free? >Regards, >Kashyap > >On Thu, Nov 12, 2020 at 11:21 PM Alexander Burger <a...@software-lab.de> >wrote: > >> Hi Kashyap, >> >> > Could you please share the example where you shared how native code >> > interface could be used to malloc a section of the heap? I believe >you >> > shared this in the last PiCon. >> >> I don't remember exactly, but it could have been something like >(using >> pil21): >> >> # Allocate 99 bytes >> : (setq P (%@ "malloc" 'P 99)) >> -> 512227229696 >> >> # Store a long integer -1 (or FFFFFFFFFFFFFFFF) >> : (struct P NIL (-1 . 8)) >> -> NIL >> >> # Read a list of 8 bytes >> : (struct P '(B . 8)) >> -> (255 255 255 255 255 255 255 255) >> >> # Store 3 bytes >> : (byte P 65) (byte (inc P) 66) (byte (+ P 2) 0) >> -> 0 >> >> # Read 8 bytes again >> : (struct P '(B . 8)) >> -> (65 66 0 255 255 255 255 255) >> >> # Read the same as a string >> : (struct P 'S) >> -> "AB" >> >> # Free the memory >> : (%@ "free" NIL P) >> -> NIL >> >> >> Instead of heap malloc() / free() you can (again, pil21) also use a >local >> buffer >> on the stack: >> >> : (buf P 99 >> (byte P 65) >> (byte (inc P) 0) >> (struct P 'S) ) >> -> "A" >> >> ☺/ A!ex >> >> -- >> UNSUBSCRIBE: mailto:picolisp@software-lab.de?subject=Unsubscribe >> -- Ceci n'est pas un courriel.
