Go Arrays for fixed sized C Arrays

[zimmski]

For every fixed sized C Array a Go array should be inserted, this includes struct members function parameters return arguments ...

[marxriedl]

I have read some threads about conversions of arrays to slices So a few questions about how do we go about this:

1. for struct arrays the main solution seems to be creating a slice of the C.[type] backed by the C pointer which results in solutions like: teamSlice := (*[1 << 30]C.team)(unsafe.Pointer(team))[:teamSize:teamSize] I don't think that is the way we should go about this. The solution we should strive to I think would be to create a slice of the go type and convert each element of the C array to its to go type and store it in the slice at the correct position
2. should we do the same for non struct arrays? or would in this case suffice the pointer backed version

[zimmski]

1.) I do not think we should use a slice at all since the array already defines the its size by definition e.g. "uintptr_t ptr_data[2]" has a size of 2. 2.) Maybe we should open a second issue or rename this issue because it would be good if this could be implemented everywhere not just for struct members. 3.) I cannot find an instance in the current Clang API that would need this implemented. These are all array references in the header files of 3.7:

306:  unsigned long long data[3];
371:  uintptr_t ptr_data[2];
382:  uintptr_t ptr_data[2];
2322:  uintptr_t data[3];
2888:  uintptr_t data[2];
4122:  unsigned int_data[4];
5183:  uintptr_t ptr_data[2];

We do not care about "data" members since they should be only modified by the struct's functions.

So if you implement this, we need some manual written tests since we cannot test it with the Clang API.

[marxriedl]

ad 1 So what would you suggest instead? There is nothing else that would have the same/similar semantics? Or did you have a function in mind e.g. getArrayElementOfData(int idx) int {...} ad 2 Renaming would be fine, I guess. However, what do you mean by "everywhere"? What are the instances besides struct members where this would apply? Global arrays? ad 3 As of now only all int_data members are filtered, all others are filtered because we do not handle arrays in general. Though I would remove all uintptr_t stuff, which is a separate issue (#50).

And I do not mind writing tests ^^

[zimmski]

ad 1: Go has arrays https://golang.org/ref/spec#Array_types I would use them for the Go binding. They are even from a memory point of view the same as in C or did I misunderstand your question?

ad 2: Everywhere would be struct member getters, function/method parameters, function/method return arguments. This issue summary just states that this should be implemented for member getters.

ad 3: IMHO we should then also improve the filter by excluding every data member.

ad 4: Removing uintptr_t might be impossible because of the GC problem. The Go GC (at least the <1.5 GO GC) gets confused by them.

ad 5: Writing tests: Go nuts!

[marxriedl]

ad 1: jikes, i got so used to slices that i forgot that go has arrays ad 2: i took the name too seriously, you mean that at every occurrence of a array in c code, a go array should be placed ad 3: kind of expected that ^^ ad 4: not removing, just ignore it in this issue since its an issue on its own (e.g., every 'thingy' that has type uintptr_t will be ignored by the generation

[zimmski]

ad 2: yep ad 4: sounds good