Open jazzy-crane opened 3 years ago
Sorry for the repeated weasel words - my understanding here isn't 100%!
Please see my fix in
https://github.com/alexbrainman/printer/tree/fix16
Hopefully it has all the answers to your questions.
Alex
I'm happy that that fixes issue #16 but this is a different issue to the string conversion and checkptr issues - more to do with whether the memory allocated for buf
could move, leaving the uint16* pointers pointing to memory within buf pointing to outside where buf
now resides. I think as buf
is heap allocated (my understanding is it escapes so can't ever be put on a stack, and thus moveable) this can't happen, but I'm wondering if that's a guarantee that holds for the future.
My concern is, (and I believe I'm correct here, but may not be so would love your input) the go runtime is free to move the address of the buf allocation?
Yes Go runtime can move buf if it was allocated on Go stack. If it is allocated on Go heap, it is not moved (but that rule can change in the future).
However the string pointers "within" the buf allocation would not change the address they are pointing at, so would no longer point to the correct place?
I am not clear what you are saying. But, if you are talking about
var v PRINTER_INFO
then Go garbage collector adjusts v.PrinterName when it moves v. Both v and memory pointed by v.PrinterName will live inside of single memory block allocated by Go. They will move together, and gc will adjust all pointers.
As I understand it, that is why the cGo rules do not allow you to pass a pointer to a Go struct containing Go pointers into cGo? - this in effect is circumventing that with a byte buffer but since it's cast it's the same thing
I do not know much about Go runtime rules. Perhaps there is a problem here, but I don't see it. If you are interested, you should discuss at
https://groups.google.com/g/golang-nuts
Alex
Alluded to here:
https://github.com/alexbrainman/printer/issues/16#issuecomment-688408767
I'm not 100% sure about this, and it's more to pick @alexbrainman brain as I think you'll have better insight into this than me.
Functions such as https://docs.microsoft.com/en-us/windows/win32/printdocs/getprinter take a single chunk of memory to return an array of (for level 5, for example) PRINTER_INFO_5 structures. This are correctly represented as such:
The way this works with the string pointers is that space is allocated for N PRINTER_INFO_5 structs + an additional amount of space at the bottom for the strings. The string pointers within the structs then point at the correct offset into that additional space.
This can be seen below (I added some debug):
My concern is, (and I believe I'm correct here, but may not be so would love your input) the go runtime is free to move the address of the buf allocation? However the string pointers "within" the buf allocation would not change the address they are pointing at, so would no longer point to the correct place? As I understand it, that is why the cGo rules do not allow you to pass a pointer to a Go struct containing Go pointers into cGo? - this in effect is circumventing that with a byte buffer but since it's cast it's the same thing
If this is a problem how can it be addressed? I presume using an allocater like LocalAlloc would do the trick ensuring the memory is not in view of the Go runtime. Though I can't see anywhere in the standard library or x/sys/windows which exposes this. C.malloc a possibility, though that introduces an (undesirable?) CGo dependency.