Hi Marc,
What the OP mentions would ideally be offered through a form something like |ffi-copy-to-u8vector|, is it not? Wrote this up as a feature request here now https://github.com/gambit/gambit/issues/645 .
Best regards, Adam
On Fri, 13 Nov 2020 at 15:54, Phillip Suero philsuero@gmail.com wrote:
Ah right - allocating an u8vector in the Scheme world is always preferable over allocating while in the C world (via ___alloc_scmobj() right), isn't it so?
And this is because allocating an object may involve a heap overflow exception, a resumed allocate attempt, a garbage collection, all these complexities are only offered by |##make-u8vector| defined in lib/_kernel.scm, which is very much preferable to invoke in a pure Scheme setting, is it not so
Thanks, Phil
On Fri, Nov 13, 2020 at 11:46 AM Phillip Suero philsuero@gmail.com wrote:
Dear Marc,
I know if I have a ___STILL u8vector, if I have a blob in the C world, I can just implement a c-lambda that will memcpy() that blob into the u8vector's memory addresses.
If the u8vector is not ___STILL however, I cannot do that as the u8vector's memory address range could change during the memcpy(), is not that so.
Is there any function in Gambit to copy a byte range from a fixed memory address into a non-___STILL u8vector? E.g. (u8vector-raw-copy! (foreign-address my-c-object) u8vector 0 length)?
Or instead, is the recommendable way to do this, that I make a ___STILL u8vector, do memcpy() to it in a c-lambda, and then at return i |u8vector-copy| this u8vector, this way the resultant u8vector is non-___STILL which is best from the point of view of memory fragmentation?
Your clarification will be much appreciated!
Thanks, Phil
Gambit-list mailing list Gambit-list@iro.umontreal.ca https://mailman.iro.umontreal.ca/cgi-bin/mailman/listinfo/gambit-list