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