Bert, That's helpful in the extreme. I still think this type of thing could and should be more obvious from crawling around in the image, and with the memcpy dispatched through something OS specific or exported by the vm so it "just works" on different platforms. Ironically, the thing that threw this in my face will probably require me to write my own library function (the data are most likely going to end up interleaved in a way I don't want). The library grabbing the data will indeed linger with the pointer, so that has to be external. The function I will end up writing can dump data into a byte array. What about cleanup of the external addresses? Do they finalize themselves? Can I safely free them when I know I am done with them? Bill Bert Freudenberg bert at freudenbergs.de Mon Aug 23 21:34:50 UTC 2010 On 23.08.2010, at 23:16, Schwab,Wilhelm K wrote:
Andreas,
Thanks for code, but should this not be in the image, associated in some way with ExternalAddress and/or ByteArray?
Can I simply use a ByteArray to make a buffer that I pass to an external library? My understanding is that it could be moved by the gc (ouch!!) Am I wrong? If there is a way to instantiate a byte array that won't move, great.
It won't move while you are calling that library. But it can move after return. So as long as the library does not retain a pointer to the buffer, this will work fine. If the lib *does* retain the pointer, use ExternalAddress allocate: or gcallocate: to make the buffer, and memcpy to fill it quickly or retrieve the data. - Bert -