size_t isnt usize and usize isnt size_t (at least on Macos)

[uucidl]

See repro at: uucidl@a96b036

ion -os osx -arch x64 bugs && \
  cc out_bugs.c -o bugs.elf && \
  ./bugs.elf ; echo "rc:$?"

Expected:

Processed 101 symbols in 2 packages
Generated out_bugs.c
rc:42

Got:

Processed 101 symbols in 2 packages
Generated out_bugs.c
<foo>/Desktop/bitwise/ion/bugs/size_bug.ion:10:25: warning:
      incompatible pointer types passing 'ullong *' (aka 'unsigned long long *')
      to parameter of type 'size_t *' (aka 'unsigned long *')
      [-Wincompatible-pointer-types]
    fetch_value(&(num), &(num_size));
                        ^~~~~~~~~~~
<foo>/Desktop/bitwise/ion/bugs/size_bug.h:3:41: note: passing argument
      to parameter 'dest_size_ptr' here
int fetch_value(void* dest_ptr, size_t* dest_size_ptr);
                                        ^
1 warning generated.
rc:42

I would have expected C apis expressed in terms of size_t to be
exposed in ion via usize. It appears that on Macos at least:

cc -E out_bugs.c | grep -E '(typedef.* uint64_t;|typedef.* size_t;)'

typedef unsigned long long uint64_t;
typedef long unsigned int size_t;

Since usize is defined as uint64, we see that these types differ.

[uucidl]

Not reproduced on Windows, where it seems we have:

typedef unsigned long long uint64_t;
typedef unsigned __int64 size_t;

Ah well. I think that usize = uint64 is kind of the correct answer, and that the long/int/short C integer zoo is messy.

Maybe usize can stay purely uint64 and builtins could simply have a c_size synonymous with size_t.

[uucidl]

I tested the idea of having a c_size, it creates some friction, as now size_t and the return value of sizeof are not anymore synonymous.