Ptr{Uint8} vs. Ptr{Int8} vs. Ptr{Cchar}

[StefanKarpinski]

We have been assuming everywhere that an array of bytes from C code looks like Array{Uint8} but now Array{Cchar} is often more appropriate, but doesn't work, e.g. with functions like bytestring. We should either use Cchar instead of Uint8 or support both Uint8 and Int8.

cc: @astrieanna, @danielmendel, @chuckha, @zachallaun.

[JeffBezanson]

Cchar is a bit unfortunate. char is typically signed, but nobody likes that. I don't think we need to use Array{Cchar}; an Array{Uint8} can be passed as a Ptr{Cchar}. I feel the C types should only be written inside ccall.

[StefanKarpinski]

That is one of the more unfortunate things about the C specs. The idea that char is neither signed nor unsigned is rather absurd. Perhaps we should take that as meaning that we're free to consider char to be unsigned as long as we ensure that LLVM doesn't generate broken code.

[StefanKarpinski]

cc: @vtjnash

[JeffBezanson]

No, we've already dealt with that. I check with sys.c:jl_is_char_signed to see what Cchar should be so we can sign or zero extend arguments properly.
Your last commit is not really necessary, because there is no reason to use Array{Cchar} in julia. You can use whatever kind of byte array you want, and it will work with Ptr{Cchar}, which is only needed in ccall. There is no real problem.

[StefanKarpinski]

The whole point of the Cfoo aliases is so that you can just use Cfoo for the corresponding foo type in C and things should work, not only in ccall, but also in Julia types that are meant to mirror C structs. However, when you have a C function that returns a Ptr{Cchar} which is a Ptr{Int8} on x86, yet all the functions that work with byte array pointers only work with Ptr{Uint8}, you get all sorts of annoying convert that are necessary. This is not hypothetical – it came up all over code we were working with today. For example, instead of writing just bytestring(p, n) you have to write bytestring(convert(Ptr{Uint8}, p), n); it's not terrible, but it happens enough to be a headache. Either we should make Cchar always be Uint8 or we should add these extra methods.

[JeffBezanson]

The signedness of char has to be correct when it is an argument type by itself, but Ptr{Int8} vs Ptr{Uint8} doesn't really matter.

[StefanKarpinski]

I'm not sure how that's relevant. The point is that you should be able to do something this:

type C_foo_struct
  bytes::Ptr{Cchar}
  len::Cint
end

# read a C_foo_struct into foo

str = bytestring(foo.bytes, foo.len)

But currently, you can't do that. You have to know that Cchar specifically should be replaced with Uint8 so that things aren't annoying. It seems like there are two reasonable options:

1. Make Cchar always be Uint8 so that this just works.
2. Make it less annoying to work with a Ptr{Cchar} when Cchar is Int8 rather than Uint8.

[JeffBezanson]

Ok, certainly nothing wrong with bytestring accepting Ptr{Int8}.