Edoardo Luppi
07/31/2023, 3:13 PMstruct addrinfo *result = NULL, *ptr = NULL, hints;
ZeroMemory(&hints, sizeof(hints));
getaddrinfo(..., ..., &hints, &result);Oleg Yukhnevich
07/31/2023, 3:27 PMval result = allocPointerTo<addrinfo>()
val hints = alloc<addrinfo>()
ZeroMemory(hints.ptr, sizeof<addrinfo>())
getaddrinfo(..., ..., hints.ptr, result)Edoardo Luppi
08/01/2023, 8:55 AMallocPointerTo?Edoardo Luppi
08/01/2023, 8:59 AMmemScoped block, or using nativeHeap directly.Oleg Yukhnevich
08/01/2023, 9:01 AMMemScope (or subclass)Oleg Yukhnevich
08/01/2023, 9:02 AMalloc should be called in memory scopeOleg Yukhnevich
08/01/2023, 9:02 AMEdoardo Luppi
08/01/2023, 9:03 AMOleg Yukhnevich
08/01/2023, 9:04 AMEdoardo Luppi
08/01/2023, 9:05 AMzeroValue might do the trick, to use in place of alloc 🤔Edoardo Luppi
08/01/2023, 9:10 AMOleg Yukhnevich
08/01/2023, 9:34 AMresult = allocPointerTo<CPointerVar<addrinfo>>Edoardo Luppi
08/01/2023, 9:34 AMresult.ptr also matches the signatureOleg Yukhnevich
08/01/2023, 9:36 AMEdoardo Luppi
08/01/2023, 9:37 AMEdoardo Luppi
08/01/2023, 9:37 AMOleg Yukhnevich
08/01/2023, 9:41 AMEdoardo Luppi
08/01/2023, 9:49 AMWSADATA wsaData;
WSAStartup(MAKEWORD(2,2), &wsaData);
Can be translated to
val wsaData = alloc<WSADATA>()
WSAStartup(0x202u, wsaData.ptr)
And this
WSADATA *wsaData;
WSAStartup(MAKEWORD(2,2), &wsaData);
Can be translated to
val wsaData = allocPointerTo<WSADATA>()
WSAStartup(0x202u, wsaData.value)
Am I correct?Oleg Yukhnevich
08/01/2023, 9:56 AMEdoardo Luppi
08/01/2023, 9:57 AMOleg Yukhnevich
08/01/2023, 10:40 AMp=alloc<TYPE> will create struct(or primitive) variable (first case, in TYPE p) and you can access it pointer via .ptr
p = allocPointerTo<TYPE> will create a pointer variable (so in C it will be TYPE *p ) and then by .ptr you can get pointer to a pointer and by .value you can get variable on which pointer is referenced
I think, that all of this is described in doc (may be with other words and examples)Edoardo Luppi
08/01/2023, 10:52 AMOleg Yukhnevich
08/01/2023, 11:52 AMallocPointerTo declaration, it’s just a simple shortcut for alloc<Pointer<TYPE>>, but because of some implementation details it could be cumbersome 🙂Oleg Yukhnevich
08/01/2023, 11:52 AMEdoardo Luppi
08/01/2023, 11:52 AMOleg Yukhnevich
08/01/2023, 11:53 AMOleg Yukhnevich
08/01/2023, 11:55 AMbuffer.copyTo (don’t remember the correct name of function)
Or you can create ordinary ByteArray and use pinning (https://kotlinlang.org/docs/native-c-interop.html#object-pinning) - example in doc uses recv 🙂Edoardo Luppi
08/01/2023, 11:56 AMEdoardo Luppi
08/01/2023, 11:57 AMOleg Yukhnevich
08/01/2023, 12:01 PMEdoardo Luppi
08/01/2023, 12:03 PMOleg Yukhnevich
08/01/2023, 12:25 PMEdoardo Luppi
08/01/2023, 12:26 PMOleg Yukhnevich
08/01/2023, 12:38 PMkotlinx.cinterop are now marked as Experimental starting from 1.9
YT issue: https://youtrack.jetbrains.com/issue/KT-57728
Blog post: https://kotlinlang.org/docs/whatsnew19.html#the-kotlin-native-standard-library-s-journey-towards-stabilization
Even before, as far as I understand, cinterop wasn’t marked as stable, but now it’s explicitly statedEdoardo Luppi
08/01/2023, 12:43 PMThey were evolved in an ad-hoc manner with a clear understanding that this is a temporary solution that will be thrown awayRelated to the cinterop types. Damn 👀
Edoardo Luppi
08/01/2023, 12:44 PMOleg Yukhnevich
08/01/2023, 12:47 PM