My original rationale for not having a c_char type is this:

• C leaves the signed-ness up to the implementation, and therefore C source code which uses char is defined to be correct regardless of the signedness that is used for char.
• Therefore we can just pick unsigned, and C source code will be correct. For example when doing translate-c, I believe it is sound to translate char to u8.
• Having the signed-ness be (non-implementation-) defined is desirable

You have pointed out a use case where this falls short:

This is easy to see when trying to create an exportable zig function which takes a char compatible parameter (impossible with the status quo).

I agree that zig should be able to export a function (or type) that uses the char C type. Although I think that explicitly using unsigned or signed is better in new C APIs, one of Zig's use cases is matching a C library's interface but having a different implementation.

But is there another use case for c_char? If not, here's an idea: c_char is exactly the same as u8, except for the purposes of generating .h files, in which case it generates char instead of unsigned char. Translate-c would still translate char as u8. We would not need to modify the zig std lib.

One more thing:

translate-c needs to check the requested target environment and generate different headers depending on the targets char signedness.

I believe clang takes care of this automatically, provided that we are passing the correct -triple argument; I don't remember if we implemented this yet or not.

One more thing: if this is for #514 (libc in zig), I suspect that the best strategy here may be to ignore the .h file generated by zig and instead manually create (or copy from musl) the .h files, and then have zig provide the implementation only. I believe the libc spec requires specifically named headers and certain kinds of macros and other one-off requirements, to the point where I would not try to wrangle zig's auto .h file generation for this particular use case.

Good points. The conversion of c_char to u8 seems like a good fit in general and is a good solution for now I think. I'll modify this PR to provide that behavior.

Partly inspired by the libc work but that was always going to need separate headers anyway due to the many macro requirements so no issues there.

Closing for now since it isn't immediately pressing and if we want c_char as a u8 alias except for the header generation it seems to require a few changes to how we deal with the type entries for u8 everywhere.

Refer to #875.