Treat char as c_char #609
Treat char as c_char #609
Conversation
|
|
|
So I experimented with having bindgen claim that char was unsigned, to see what breaks. The answer is: this input gives But I reckon that supports what I said above: this header was broken in the first place, because if you set a char to -1, you're asking for trouble on platforms where char is unsigned. |
|
☔ The latest upstream changes (presumably #608) made this pull request unmergeable. Please resolve the merge conflicts. |
|
So compared to this, your #610 was different in three ways:
I think this last is at best unnecessary: clang already has four types, precisely to distinguish between "signed char", "unsigned char", "char that happens to be signed" and "char that happens to be unsigned". So we can just use them directly. I'll update this pull request so that it makes that change instead. |
|
Looks good, thanks! Sometimes I wish the libclang docs would be a bit better about that stuff, I just didn't want to dig into LLVM's source to see the difference between those yesterday. @bors-servo r+ Thanks again! |
|
📌 Commit aa04308 has been approved by |
Treat char as c_char Per #603. This still leaves `bindgen` having to make a call as to what to say when asked whether `Char` `is_signed()`. I've opted just to leave this as `true`, on the grounds that: * I don't currently understand an example where it matters * I suspect that if there are cases where it matters, then it shouldn't! * Because by definition, use of unadorned `char` in the original header says that it doesn't care about signedness * (signed is the common case, so that's a more sensible guess than unsigned)
|
☀️ Test successful - status-travis |
Per #603.
This still leaves
bindgenhaving to make a call as to what to say when asked whetherCharis_signed(). I've opted just to leave this astrue, on the grounds that:charin the original header says that it doesn't care about signedness