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