code review 53840043: syscall: allocate 64 bits of "basep" for Getdirentries

syscall: allocate 64 bits of "basep" for Getdirentries
Recent crashes on 386 Darwin appear to be caused by this system call
smashing the stack. Phenomenology shows that allocating more data
here addresses the probem.
The guess is that since the actual system call is getdirentries64, 64 is
what we should allocate.

Should fix the darwin/386 build.

[r, 2014-01-17 20:59:19]

Hello rsc (cc: golang-codereviews@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go

[rsc, 2014-01-17 21:01:38]

LGTM assuming it still works with the suggested edit

https://codereview.appspot.com/53840043/diff/1/src/pkg/syscall/syscall_bsd.go
File src/pkg/syscall/syscall_bsd.go (right):

https://codereview.appspot.com/53840043/diff/1/src/pkg/syscall/syscall_bsd.go...
src/pkg/syscall/syscall_bsd.go:70: var base =
uintptr(unsafe.Pointer(new(uint64)))
var base = (*uintptr)(unsafe.Pointer(new(uint64)))
and then no & on next line.
the & is increasing the indirection one extra level from where it was before.

[rsc, 2014-01-17 21:05:37]

I have confirmed in the OS X sources that getdirentries64 is expecting a pointer
to a 8-byte-wide value. The old getdirentries was just 4 bytes. We've just been
lucky because the memory allocator never allocates fewer than 16 bytes. But
moving it onto the stack we were not as lucky.

[r, 2014-01-17 21:18:14]

*** Submitted as https://code.google.com/p/go/source/detail?r=6d8511a61827 ***

syscall: allocate 64 bits of "basep" for Getdirentries
Recent crashes on 386 Darwin appear to be caused by this system call
smashing the stack. Phenomenology shows that allocating more data
here addresses the probem.
The guess is that since the actual system call is getdirentries64, 64 is
what we should allocate.

Should fix the darwin/386 build.

R=rsc
CC=golang-codereviews
https://codereview.appspot.com/53840043