cmd/cgo: C.size_t issues on Xcode 5

[gopherbot]

by os2nuke:

This is a link to the related issue with C.malloc:

https://golang.org/issue/5926

What steps will reproduce the problem?
Build a cgo program which uses C.calloc() and pass a C.size_t parameter.

What is the expected output?
Build without errors.

What do you see instead?
cannot use _Ctype_size_t(length + 1) (type C.size_t) as type C.ulong in function argument

Which operating system are you using?
OS X 10.9 Mavericks

Which version are you using?  (run 'go version')
go version devel +67b829e5a2a8 Fri Sep 27 20:38:52 2013 -0700 darwin/amd64

Please provide any additional information below.

[dominikh]

Comment 1:

realloc will have the same problem.

[dominikh]

Comment 2:

Can we consider this for 1.2 still? It seems to be in the same boat as the malloc issue
that was fixed.

[ianlancetaylor]

Comment 3:

Want to write a patch along the same lines as the one that fixed malloc?

Labels changed: added priority-soon, go1.2maybe, removed priority-triage.

[rsc]

Comment 4:

I did C.malloc because it is effectively a required way to allocate memory.
C.calloc is much less important, because people can always call C.malloc +
C.memset.
I don't know where this will end.

[dominikh]

Comment 5:

I can see how calloc, and probably realloc too, are less important. But I think that if
these 3 are the only ones that need this sort of fix, it's still worth it, mostly to
keep existing code from failing. 
Now, if you tell me that there are like 5 other functions that have the same problem,
then yes, it becomes somewhat pointless to fix them. But if it's limited to these 3, why
not go for it?

[rsc]

Comment 6:

As Ian said, please send a CL. Might as well handle the zero cases there
too.

[dominikh]

Comment 7:

https://golang.org/cl/14602043/

[dominikh]

Comment 8:

Considering issue #6575 (the same issue, with memcpy) I don't think adding more wrappers
is the right solution after all.

[minux]

Comment 9:

i agree.

[ianlancetaylor]

Comment 11:

Issue #6575 has been merged into this issue.

[dominikh]

Comment 12:

For what it is worth, it's not strictly an OS X issue but a clang issue. Anyone who
chooses to use clang instead of gcc on Linux will have the exact same problem.

[ianlancetaylor]

Comment 13:

Are you sure this is clang related?  I would have thought it would have to do with the
system header files.  Can anybody reproduce this on GNU/Linux with clang?  I was unable
to reproduce it using
Ubuntu clang version 3.0-6ubuntu3 (tags/RELEASE_30/final) (based on LLVM 3.0)

[dominikh]

Comment 14:

That's how I tested my patches for calloc and realloc, by installing clang on a (Gentoo)
Linux system and setting CC=clang.
clang version 3.3 (tags/RELEASE_33/final)
and
LLVM version 3.3
Built Sep 28 2013 (16:54:11).

[minux]

Comment 15:

great! thank you for the info, now i can take a look at the problem
without reinstalling my Mac.

[minux]

Comment 16:

@dominik.honnef, i installed LLVM 3.3 + Clang 3.3 from source on my Gentoo machine,
but ./all.bash failed to reproduce the problem, the only failure is:
# ../misc/cgo/testcdefs
# _/home/minux/go/go.hg/misc/cgo/testcdefs
./cdefstest.h:13 ./cdefstest.c:6 array size must be a positive constant
./cdefstest.h:15 ./cdefstest.c:6 array size must be a positive constant
./cdefstest.h:17 ./cdefstest.c:6 array size must be a positive constant