Question: PtrTips to use a byte array for a const char*

[xlab]

Question: PtrTips to use a byte array for a const char*

[deepakjois]

I understand the default behavior. I could just convert a byte array into a string and pass it into the function to get around I guess.

You have already closed this issue, so I am not sure how much of a scope there is for discussion. I am also not sure what qualifies as a ‘serious reason’. The harfbuzz package uses ‘const char *’ in many places to store binary blob-like data. So a const char * is actually more than just a string. So it seems a bit arbitrary to make a mandatory conversion to string. It is definitely a good default behavior, but it should be overridable. Otherwise, I will have to convert all binary data that I read from files into a string before I pass it to Harfbuzz. That seems very un-Go-like, and defeats the purpose of autogenerating the bindings.

[xlab]

@deepakjois I fully understand your concern, the problem is that it cannot be easily overridden at this moment, the fix requires some fundamental changes and I'm not ready to do this right now.

I closed this issue but I'll keep this discussion in mind. I want to collect more issues like that so it will be a critical mass that will drive the change or someone would find a potential problem with performance or unsafe access that really affects the sanity.

As for "Go-like" principle, the API consistency is far more important than the Go-likeness of types, because they never be like Go ones. Of course that's just my opinion, but I just letting you know why is this. Converting an immutable const char * into a mutable type []byte is the same thing as converting long long into uint8. These things cannot be "overriden" in manifest as well.

Otherwise, I will have to convert all binary data that I read from files into a string before I pass it to Harfbuzz

That's not that hard to do. You can include these functions into your generated package:

func unsafeString(b []byte) string {
    hdr := (*sliceHeader)(unsafe.Pointer(&b))
    return *(*string)(unsafe.Pointer(&stringHeader{
        Data: hdr.Data,
        Len:  hdr.Len,
    }))
}

func ReadData(r io.Reader) string {
    buf, _ := io. ReadAll(r)
    return unsafeString(buf)
}

func Data(b []byte) string {
    return unsafeString(b)
}

[deepakjois]

Ok, sorry about this. It seems like it is working. But this is happening to me a lot. I think I make a change and it does not take effect until I delete all the generated code and run cgogen after that.

[deepakjois]

Ok sorry…no its not working. But I have more details about the problem. See replication here:

https://github.com/deepakjois/cgogentest/tree/3af0a09204b78c0e6d01bc3282593fe3459ecdb7

Basically, const char* seem to get treated specially. If I change const char* to char *, then it works.

[xlab]

Yes, that has been done intentionally, from the Go spec:

A string value is a (possibly empty) sequence of bytes. Strings are immutable: once created, it is impossible to change the contents of a string. The predeclared string type is string.

That is exactly what const char* is. There is no allocation passing that value into C.
I'll reopen the issue add tips for that only if there will be some serious reason. Thanks for caring.

[deepakjois]

Thanks for the clarification. It is good to hear that you are collecting the issues. Hopefully there is a good solution for this in the future.

As for your code, where does the *sliceHeader and &stringHeader come from?

[xlab]

They usually are put in cgo_helpers.go when some string conversion occurs, so I expect that the generated package have it. Otherwise these are just renamed reflect.SliceHeader and reflect.StringHeader, I prefer to avoid including the reflect package and carry them around as private.

type stringHeader struct {
    Data uintptr
    Len  int
}

type sliceHeader struct {
    Data uintptr
    Len  int
    Cap  int
}

[theCarlG]

I have the same issue when trying to create go-bindings for libdivecomputer, it's an open source library for communication with dive computers from various manufacturers. And when it downloads the dive records from the dive computer it will pass the raw binary data to a callback as a const unsigned char *data and when the generated bindings use packPUcharString to convert this data into a string the resullt will be an empty string.

Here is an [mplementation of the callback in C: dctool_download.c
And here is an example how is used: shearwater_petrel.c

And I have to say that c-for-go is a really neat tool :)