Hello all! I'm trying to figure out how the NativeCall interface releases memory for objects with native representation, and I could use some help.
For what I can see: * CPointer never frees anything https://github.com/MoarVM/MoarVM/blob/master/src/6model/reprs/CPointer.c#L148 * CStr always frees the allocated memory https://github.com/MoarVM/MoarVM/blob/master/src/6model/reprs/CStr.c#L63 * CStruct never frees, but has a comment saying maybe it should https://github.com/MoarVM/MoarVM/blob/master/src/6model/reprs/CStruct.c#L664 I agree that CPointer shouldn't do anything special: it's essentially a number, in general we don't know anything about it, so it's best to leave it alone. For CStr, I'm not clear on what happens: I haven't found code that actually uses it. For CStruct (and CPPStruct, and CUnion), I'm pretty sure that both "never free" and "always free" are bad. Some C functions will return pointers to data they have allocated, and expect you to free, either with the normal "free" function or with some library-specific call. Some other will return pointers to internal data that you should not touch. Some will expect you to allocate memory, and will write there. The current behaviour of not freeing is definitely better than going around and calling "free" on every pointer, but it leaks. I'd like to be able to mark an instance as "owned by the Perl side", and specify how to free it. It has to be per-instance, since different values of the same type may be owned by different "sides". I see these four cases: * object allocated by Perl, passed to C * becomes owned by C * or stays owned by Perl * object allocated by C, returned to Perl * becomes owned by Perl * or stays owned by C A C-owned object will be freed as a side-effect of some future call. A Perl-owned object may need to to be freed by: * a normal call to "free" * a call to a specific C function Does the above make any sense? Am I on the right track? How would I go about implementing that thing? -- Dakkar - <Mobilis in mobile> GPG public key fingerprint = A071 E618 DD2C 5901 9574 6FE2 40EA 9883 7519 3F88 key id = 0x75193F88 The first time, it's a KLUDGE! The second, a trick. Later, it's a well-established technique! -- Mike Broido, Intermetrics
pgpF62DYdtiTD.pgp
Description: OpenPGP digital signature
