C integer types as aliases of zig integers

[daurnimator]

Currently c_ushort != u16.

15:14:52 | andrewrk | because the C integer types have different bit widths based on targets
15:15:15 | andrewrk | it matters for the C ABI

Instead, I propose that e.g. c_ushort just becomes an alias for the relevant u16/u32/etc.

As @andrewrk notes, this could happen in the standard library itself

15:20:11 | andrewrk | which would be renamed to std.c.int

[andrewrk]

I'm for this, as long as we can't think of any problems this will cause.

[andrewrk]

Ah, I remember why we need C integer types now. See #875. It's for the purpose of exporting a C ABI compatible function.

export fn foo() c_ushort { return 123; }

is different than

export fn foo() u16 { return 123; }

Even though they always have the same bit count, one of them generates the C code:

unsigned short foo(void);

And the other:

uint16_t foo(void);

It also matters for compile error messages when dealing with translated C code, as well as a more general resilience toward accidents with ABIs and different targets - not because the way C integers work is better, but because when porting C code or otherwise using a C ABI that uses such types, trying to port them to types which don't match under all targets could be an easy mistake to make.

That being said, I'll leave this proposal open for consideration because it is possible to take a different strategy of generating .h files, at least we can consider what that would look like. I believe such a strategy would be related to multibuilds (#3028).

[daurnimator]

If a zig file @cImports something that does:

#if ((INT_MAX >> 15) >> 15) >= 1
typedef int  i32
#else
typedef int  i16
#endif

Then unless we repeat the ifdefery back in the generated .h file, then we're not correct anyway.