Can anyone confirm if `char**` in C is represented as `CPointerVar<Char>` in kotlin?

# kotlin-native

[Big Chungus]

Can anyone confirm if char** in C is represented as CPointerVar<Char> in kotlin?

[vbsteven]

On Linux I've seen it mapped mostly as CPointerVar<ByteVar>

[vbsteven]

Assuming you are working on GTK, I've used the following for most of the char**-related conversions.

/**
 * Convert a Kotlin [List<String>] into its native equivalent.
 */
public fun List<String>.toCStringList(scope: MemScope): CArrayPointer<CPointerVarOf<CPointer<ByteVar>>> = with(scope) {
    return allocArrayOf([e-mail] { it.cstr.getPointer(this) } + null)
}

/**
 * Convert a native char** into a Kotlin [List<String>].
 */
public fun CArrayPointer<CPointerVarOf<CPointer<ByteVar>>>.toKStringList(): List<String> = buildList {
    var i = 0
    while (this@toKStringList[i] != null) {
        add(this@toKStringList[i]!!.toKString())
        i++
    }
}

PoC code, this won't work for all methods. As sometimes the char** is null-terminated, and sometimes it has a fixed size

[Big Chungus]

Thanks

[Big Chungus]

Do type** in c always mean an array or are there other ways to represent an array in C?

[vbsteven]

not always an array, could also be a pointer to pointer

[vbsteven]

in the GTK case, you'll see ** for GError out pointers, where you want to pass in a pointer to a GError pointer, so GTK can fill it with a pointer to the error when it encounters an error

[Big Chungus]

Are you saying there is no standard way to declare an array in C, but rather just type** convention?

[vbsteven]

I'm not super fluent in C, so there might be other ways. In the case of string "arrays" here, the char** means a pointer to the first element in an array of char*

[vbsteven]

and c strings, if I'm not mistaken, are also "arrays", and char* means a pointer to the first element in an array of char, And C-strings are an array of char terminated by \0

[Big Chungus]

Odd, why not null terminated?...

[vbsteven]

so for the char** case for GTK null-terminated string arrays, in memory it will look like [ptr, ptr, ptr, null]. where each ptr points to [char, char, char, \0], something like that

[Big Chungus]

Thanks, that's super clear now. I remember having to do some pointer voodoo like this back at the university and not liking it very much 😀

[vbsteven]

in the case of C strings, the \0 is a null byte (because char is typically byte). In the case of char** since it's an array of pointers, the final element is a null pointer

[Big Chungus]

Ah, makes sense now

[vbsteven]

also cinterop handles the C-strings for you mostly. and you can use toKstring() to convert it to a Kotlin String. and you can do myKotlinString.cstr to get a char* pointer to the c-String for your kotlin string

[Big Chungus]

Yeah, I'm aware of those. Just trying to understand how it all ties together under the hood.

[Landry Norris]

C does let you declare char* strings[size]; , which is explicitly an array. I believe Kotlin will read this as a CArrayPointer turns out it’s CValuesRef. CArrayPointer comes from allocArray.

[Landry Norris]

For a real world example, the FFmpeg sws_scale sees *uint8_t* *const srcSlice[] as srcSlice: CValuesRef<CPointerVar<uint8_tVar>> in Kotlin

[ephemient]

C arrays decay to pointers across most boundaries

[Landry Norris]

Also, small pedantic note on \0 vs null (NULL in C). Both are actually the same! ‘\0’ is just a nice way of saying 0, and so is NULL. C doesn’t really have a strong concept of runtime types, like Kotlin or Java. You could set char c = (char) NULL just as easily. In the same way, char** words is essentially equivalent to char* words[] . C also lets you do interesting things like 2[words] = "This works" or *(words + 3) = "This works too" . C has been around for a long time, so there’s a lot of variations on almost anything. Some lists, like strings, use a null terminator, and others, like the srcSlice I mentioned earlier will require you to calculate the size (the calculation for srcSlice length is not fun) or know it.

[ephemient]

in theory, standard C doesn't mandate that NULL is represented by 0, only that it is integer convertible to/from 0, but it does mandate that a byte with all bits set to 0 is interpreted as a null character

[ephemient]

https://c-faq.com/null/machexamp.html has some specific examples of historical architectures where NULL was not physically zero

[Landry Norris]

C is just one of those languages that gets more terrifying as you look further into it. No wonder one of my professors in college refused to acknowledge that anything past ANSI C exists...