This is a spinoff from #13467

Here's a "minimal" reproduction, I'll include my concrete usecase below.

Consider two vendors which provide equivalent implementations of ~*~something~*~ -- in this toy example, they are providing a function called My_foo

vendora/include/foo.h

typedef long My_ssize_t;

void My_foo(My_ssize_t);

vendora/src/foo.c

#include "foo.h"

void My_foo(My_ssize_t x) {}

vendorb/include/foo.h

typedef long My_ssize_t;

void My_foo(long);

vendorb/src/foo.c

#include "foo.h"

void My_foo(long x) {}

differences

So you don't have to play "spot the differences", both vendors provide a typedef for My_ssize_t as an alias to long. The two vendors define equivalent functions, but one vendor chose to use long in the function definition and the other chose to use the typedef My_ssize_t.

compiling the c bits to shared libraries:

gcc -shared -Ivendora/include -o vendora/libfoo.so vendora/src/foo.c
gcc -shared -Ivendorb/include -o vendorb/libfoo.so vendorb/src/foo.c

main.go

package main

// #include "foo.h"
import "C"
import "fmt"

func main() {
	C.My_foo(C.My_ssize_t(9001))
	fmt.Println("It worked!")
}

Running (compiling) against vendora

$ LD_LIBRARY_PATH=$PWD/vendora \
>     CGO_CFLAGS=-I$PWD/vendora/include \
>     CGO_LDFLAGS="-L$PWD/vendora -lfoo" \
>     go run main.go
It worked!

Running (compiling) against vendorb

$ LD_LIBRARY_PATH=$PWD/vendorb \
>     CGO_CFLAGS=-I$PWD/vendorb/include \
>     CGO_LDFLAGS="-L$PWD/vendorb -lfoo" \
>     go run main.go
# command-line-arguments
./main.go:8: cannot use C.My_ssize_t(9001) (type C.My_ssize_t) as type C.long in argument to _Cfunc_My_foo

Here I expect the same output as running (compiling) against vendora

My description of the problem

Despite My_ssize_t and long being identical C types in the same module, they are treated as different go types.

My concrete problem

My concrete problem actually has to do with interfacing with CPython / pypy, you can read more about it in the other issue: #13467 (comment)

My thoughts

I'm not a seasoned go developer, but my initial inclination that would at least solve my problem would be to make typedef primitive x into type aliases in cgo -- is this reasonable? where do I start hacking 😄