4 ms·
Dang, I always figured that would be unsafe eventually. I wonder, does this make stuff like this unsafe: var thing C.thing; C.somefunc(&thing) i.e. can stack
by Daemon404 11y ago
Dang, I always figured that would be unsafe eventually.
I wonder, does this make stuff like this unsafe:
var thing C.thing;
C.somefunc(&thing)
i.e. can stack address change now?
- danieldk 11y agoThe Go spec does not contain the stack or heap, so I guess that in principle it's fair game for the collector to relocate it in memory. In some future version it's only safe to use memory in C-land that was allocated in C-land.
- AnimalMuppet 11y agoWouldn't it be safe to use in C-land as long as you kept a reference to it in Go-land? Something like: Create memory in Go-land Use memory in C-land Dispose of reference to memory in Go-land That becomes a bit problematic if the C-land use is for a long-running process - you need a go object that owns the memory that has a lifetime that (at least) matches the lifetime of the C code execution.
- danieldk 11y agoCurrently, yes. Once Go has a moving garbage collector (soon-ish), no. A moving garbage collector can move objects around. This would invalidate pointers in C, since the GC can run concurrently with C code (even if it didn't, it would invalidate pointers to object allocated in Go in C structs). To make things work, you have to allocate date used in C in C and pass Go variables only by value.