ChezScheme
ChezScheme copied to clipboard
cisco
ftype-ref should take bytevector as argument
hi there, when data are read/write through normal binary port, they should be able to pack/unpack using the same function that ftype has. naturally, if ftype-ref/ftype-set! family can have bytevectors as argument will be make life easier.
Extending the existing ftype-ref and ftype-set! forms to work for bytevectors would add dispatch overhead to the generated code and increase the code size. A better option might be to add bytevector-specific versions of the forms. I would be inclined to limit those versions to operate on scalar fields and not to support a bytevector version of ftype-&ref to avoid issues with pointers into and out of bytevectors.
Partially agree, but defining a struct for bytevectors and foreign-pointer shares something in common: name, size(type, sign ), position and padding(align).
current syntax ftype-&ref can give position information(using form: (ftype-&ref type 0) , but others are not very handy to achieve.
While bytevectors and ftypes might seem like similar things, since they both point at arbitrary blobs of data, they are fundamentally different in how they are structured.
A bytevector is a scheme object with a header word that identifies the object as a bytevector, stores the length of the bytevector, and indicates if the bytevector is mutable. Like other scheme objects, bytevectors may move in memory during garbage collection.
An ftype, on the other hand is a record type with an extended record type descriptor and a single raw machine word that is a pointer into memory. The extended record type descriptor contains information about the structure of the ftype (though of course it is foreign memory, so the ftype system is relying on the programmer to supply it with a valid pointer before it starts to reference it).
All of that said, it would certainly be possible to create a structured data overlay on type of the bytevector structure. This could very likely be implemented on top of the existing bytevector reference functions and it would be safer than using foreign memory, since the extent of the bytevector can be checked before the reference happens.
It is also possible, though probably a bit ill advised, to use the ftype system with a bytevector by getting a pointer to the where the data of the bytevector starts and treating it like it is a foreign pointer. You'd likely want to lock the bytevector before doing this, since it could otherwise move out from under the ftype, which remember is storing a raw pointer to it.
Of course, getting your hands on the raw pointer is tricky in Scheme, but the C interface does provide Sbytevector_data, which bears the appropriate (though perhaps understated) warning:
/* Warning: Sbytevector_data(x) returns a pointer into x. */
Of course, in this case that is what you are after, but you should be very careful not to accidentally scribble past the end of the allocated bytevector into some other memory within the Scheme heap, which is very likely to wreak havoc with your program.
Minor update: the v9.9.9 merge added object->reference-address, which serves as a Scheme version of Sbytevector_data (and equally dangerous).
