> > Please be careful with the GC of the pointer.
> > It means that you must ensure that the pointer associated with the Neko
> > value is not used anymore by any other data structure in your program :)
>
> so true once more- although this seems to be mostly a matter of the C side of
> bindings, and such left to the binding developer to take care of-- if- there
> is a way to mark a value as being referenced from C?
Yes of course, it's the binding developers that should take of this by
keeping a reference on the "value" cptr while it's in-use.
> do you agree though, that the way i currently do it should be pretty safe
> security-wise, at it doesnt allow neko programs to write into arbitrary
> memory areas? this is my primary concern on the long run- crashes due to
> forgetting about pointer handling i could live with :)
Yes it should be ok.
> you say that once understood it's easy to implement- but i admit i dont
> really know how i would go about it if i'd have some pointer that i want to
> both pass to neko and keep handling within C (again, can i increase the
> refcount from C? i guess yes, but how?). I think both C memory handling and
> garbage collection are quite clear to me, although interaction between the
> two obviously poses a bit of a problem to my feeble mind :)
For example let's say you have a C allocated "image*" that use a cptr.
You will need to do the following :
typedef struct {
value cptr;
image *img;
} abstract_image;
DEFINE_KIND(k_image);
#define val_image(v) ((abstract_image*)val_data(v))
This way you ensure that the "value cptr" is reachable by the GC as long
as the abstract block containing the "image*" is alive. It's just a
matter of keeping accesible values in order to ensure a certain GC order.
> > I'm checking your code and see that you're defining several kind of
> > abstracts - one per pointer type. Does it makes really sense to have
> > such an "high level" definition ? For instance you could just treat a
> > pointer as a memory block where you can store several kind of RAW data.
>
> well, yes- but then it would be rather hard to read and write elements in
> case the pointer is an array of ints or the like. for example, OpenGL
> expresses its matrices as simple float*, and i surely want to set them from
> neko. i would need to "encode" the data myself, likely taking care of endian
> issues from neko, etc.
Why not have different accessors ?
cptr_get_int( value cptr, value index )
cptr_set_int( value cptr, value index, value v )
cptr_get_float( value cptr, value index )
cptr_set_float( value cptr, value index, value v )
....
The only difference is that you store the number of bytes of the cptr
and that you access using aligned indexes.
> the current way assures that you're not passing pointers to data of the wrong
> type to functions expecting specific data. for raw buffers of some stuff it
> might make sense to just handle them abstractly, but if i really want neko to
> access the data, this makes stuff much easier- doesnt it?
In C the pointers does not really have a type. They are just memory
blobs. For instance some people might want to create a FLOAT CPTR from a
file stored on disk. While not permit them then to read bytes from the
file and write bytes to the CPTR ?
It would be much more powerful to have a single "memory" kind with
get/set accessors for the different C type, and the ability to "blit"
data from/to a Neko string for instance.
Nicolas
--
Neko : One VM to run them all
(http://nekovm.org)
