Message ID | CAFULd4YFKx1Y8EX175ykWi19s_x+Ltp=26kRaB4tjJVxo4rYnA@mail.gmail.com |
---|---|
State | New |
Headers | show |
On Fri, Feb 8, 2013 at 9:42 AM, Uros Bizjak <ubizjak@gmail.com> wrote: > > Please note, that looking at generated libcalls.go, there are many > other possible signed/unsigned issues of the same type. Since this all > happens on x86_64 (where go int is apparently 64bit), it looks that it > is very important to distinguish int from _C_int in glue source. Wow, thanks for tracking this down. I see that I did a pretty bad job of using _C_int correctly. I committed this patch to fix the problem. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu. Ian
Index: go/syscall/libcall_linux_utimesnano.go =================================================================== --- go/syscall/libcall_linux_utimesnano.go (revision 195879) +++ go/syscall/libcall_linux_utimesnano.go (working copy) @@ -9,7 +9,7 @@ import "unsafe" //sys utimensat(dirfd int, path string, times *[2]Timespec, flags int) (err error) -//utimensat(dirfd int, path *byte, times *[2]Timespec, flags int) int +//utimensat(dirfd _C_int, path *byte, times *[2]Timespec, flags int) _C_int func UtimesNano(path string, ts []Timespec) (err error) { if len(ts) != 2 {