[mac] false pos in write_nocancel: user_size_t header decl seems wrong

_From [bruen...@google.com](https://code.google.com/u/109494838902877177630/) on February 20, 2014 18:27:01_

Running tests/free on Mac:

~~Dr.M~~ Error `#4`: UNINITIALIZED READ: reading 0xbffe6e4c-0xbffe6e50 4 byte(s) within 0xbffe6e48-0xbffe6e50
~~Dr.M~~ # 0 system call write_nocancel parameter value `#2`
~~Dr.M~~ # 1 libsystem_c.dylib!__swrite
~~Dr.M~~ # 2 dyld!dyld::initializeMainExecutable
~~Dr.M~~ # 3 libsystem_c.dylib!_swrite
~~Dr.M~~ # 4 libsystem_c.dylib!__sflush
~~Dr.M~~ # 5 libsystem_c.dylib!__sfvwrite
~~Dr.M~~ # 6 libsystem_c.dylib!__vfprintf
~~Dr.M~~ # 7 libsystem_c.dylib!__v2printf
~~Dr.M~~ # 8 libsystem_c.dylib!__xvprintf
~~Dr.M~~ # 9 libsystem_c.dylib!vfprintf_l
~~Dr.M~~ `#10` libsystem_c.dylib!printf
~~Dr.M~~ `#11` main [/drmemory/git/src/tests/free.c:63]

Also seems to have a bogus frame => investigate separately
Happens in debug too (w/o the bogus frame -- so won't be easy to
investigate that):

app xsp=0xbff15e3c
arg 0 = 0x1
arg 1 = 0x10b56510
arg 2 = 0x9
arg 3 = 0x9078c3
arg 4 = 0xbe5314
arg 5 = 0xbff16238
system call `#397`==397.0 write_nocancel
Error `#4`: UNINITIALIZED READ: reading 0xbff15e4c-0xbff15e50 4 byte(s) within 0xbff15e48-0xbff15e50
#0 system call write_nocancel parameter value `#2`
#1 libsystem_c.dylib!__swrite (0x983374e0 ) modid:26
#2 libsystem_c.dylib!_swrite (0x9833762d ) modid:26
#3 libsystem_c.dylib!__sflush (0x98330928 ) modid:26
#4 libsystem_c.dylib!__sfvwrite (0x98333228 ) modid:26
#5 libsystem_c.dylib!__vfprintf (0x9833c9c7 ) modid:26
#6 libsystem_c.dylib!__v2printf (0x9835f1da ) modid:26
#7 libsystem_c.dylib!__xvprintf (0x9835f694 ) modid:26
#8 libsystem_c.dylib!vfprintf_l (0x98338894 ) modid:26
#9 libsystem_c.dylib!printf (0x98336997 ) modid:26
#10 main [/drmemory/git/src/tests/free.c:63](0x000eaf33 INT_MAX)
return (EINVAL);

But it would return EINVAL if it took 64-bit: so it seems that
syscalls.master is wrong?

Are these types wrong:
../include-10.9.1/i386/types.h-#if !defined(_ANSI_SOURCE) && (!defined(_POSIX_C_SOURCE) || defined(_DARWIN_C_SOURCE))
../include-10.9.1/i386/types.h-/\* These types are used for reserving the largest possible size. */
../include-10.9.1/i386/types.h-typedef u_int64_t user_addr_t;
../include-10.9.1/i386/types.h:typedef u_int64_t user_size_t;
../include-10.9.1/i386/types.h-typedef int64_t user_ssize_t;
../include-10.9.1/i386/types.h-typedef int64_t user_long_t;
../include-10.9.1/i386/types.h-typedef u_int64_t user_ulong_t;

I've been assuming user_addr_t matches pointer sizes! It's used in
SYS_open for file path, SYS_mkdir, etc.: surely those wouldn't work if it
were really 64-bit.

Conclusion: those user_ types are not the size they are typedef-ed as.

_Original issue: http://code.google.com/p/drmemory/issues/detail?id=1448_