C 라이브러리와의 cinterop

Sometimes the code you need is a plain C library. Kotlin/Native can call it directly through a tool called cinterop. 🔌

cinterop reads C headers and generates Kotlin bindings. After that, the C functions and types look like ordinary Kotlin declarations you can call.

You describe the library in a small def file: which headers to read and which library to link. This is the recipe cinterop follows.

Inside the kotlin block you register a cinterop entry for your target. Gradle then runs the tool and adds the generated bindings to compilation.

Once generated, a C function is just a Kotlin function. Import it from your def package and call it like any other shared function.

A raw C pointer maps to Kotlin CPointer. It is typed, so the compiler knows what it points at instead of leaving you with a bare address.

C does not free things for you. Allocate inside a memScoped block so Kotlin releases the native memory automatically when the block ends.

Use helpers to convert between Kotlin and C strings. A Kotlin String becomes a C buffer with cstr, and you convert back when reading results.

C structs map to Kotlin classes with field access. An opaque type you never inspect is just a pointer you pass straight back to the library.

cinterop bindings exist only for Kotlin/Native targets like iOS. Wrap the calls behind expect/actual so commonMain stays platform-free.

Hide pointers and memScoped behind a friendly Kotlin API. Callers get clean types and never touch raw C details directly.

A quick check on managing C memory from Kotlin.

You saw that a def file plus Gradle generates Kotlin bindings for a C library, pointers map to CPointer, and memScoped manages native memory. 🎉