possible memory leaks? about go-raylib

[chunqian]

Sorry, I'm not on that server
I'll take a look at Valgrind Memory Check today and I'll find out why

[chunqian]

package main

// #include <stdio.h>
// #include <stdlib.h>
//
// static void myprint(char* s) {
//   printf("%s\n", s);
// }
import "C"
import "unsafe"

func main() {
  cs := C.CString("Hello from stdio")
  C.myprint(cs)
  C.free(unsafe.Pointer(cs))
}

valgrind test
==16236== LEAK SUMMARY:
==16236==    definitely lost: 0 bytes in 0 blocks
==16236==    indirectly lost: 0 bytes in 0 blocks
==16236==      possibly lost: 1,152 bytes in 4 blocks
==16236==    still reachable: 0 bytes in 0 blocks
==16236==         suppressed: 0 bytes in 0 blocks
==16236== Rerun with --leak-check=full to see details of leaked memory

package main

// #include <stdio.h>
// #include <stdlib.h>
//
// static void myprint(char* s) {
//   printf("%s\n", s);
// }
import "C"
// import "unsafe"

func main() {
  cs := C.CString("Hello from stdio")
  C.myprint(cs)
  // C.free(unsafe.Pointer(cs))
}

==16452== LEAK SUMMARY:
==16452==    definitely lost: 17 bytes in 1 blocks
==16452==    indirectly lost: 0 bytes in 0 blocks
==16452==      possibly lost: 1,152 bytes in 4 blocks
==16452==    still reachable: 0 bytes in 0 blocks
==16452==         suppressed: 0 bytes in 0 blocks
==16452== Rerun with --leak-check=full to see details of leaked memory

tools like valgrind don’t understand Go’s calling conventions or stack layout.

golang use cgo, valgrind's possibly lost is useless.

Thanks for clearing that up! That makes more sense.