fix: use c_char from crate root

[mekosko]

Most likely this is a typo and c_char from crate root should be used. If this is intentional and there must be an unsigned char, then it may be better to specify u8 instead of c_char.

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @JohnTitor (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[tgross35]

This seems fine and it should indeed be a char per the docs https://man.freebsd.org/cgi/man.cgi?unix(4).

If this is intentional and there must be an unsigned char, then it may be better to specify u8 instead of c_char

Is there any specific problem here or cases where libc::c_char does not line up with std::ffi::c_char? Usually they should coincide.

In any case, please rebase so the merge commit can be dropped.

@rustbot author

[ChrisDenton]

I have a PR that intends to add a test that ensures that they are the same. #3616

This is moved from rustc where we skip certain platforms that don't have libc in the sysroot. But we really should be testing them, hence moving the test into libc.

[mekosko]

Is there any specific problem here or cases where libc::c_char does not line up with std::ffi::c_char? Usually they should coincide.

Yes, I was trying to port libc crate to proprietary system with network stack from bsd, this system's char is signed but for bsd it is unsigned, and they mismatched. (If I remember everything correctly, it was more than two months ago)

[tgross35]

Is there any specific problem here or cases where libc::c_char does not line up with std::ffi::c_char? Usually they should coincide.

Yes, I was trying to port libc crate to proprietary system with network stack from bsd, this system's char is signed but for bsd it is unsigned, and they mismatched. (If I remember everything correctly, it was more than two months ago)

Meaning, std had the correct type but libc was wrong? If this is accurate, could you submit a PR here fixing that?

[mekosko]

Meaning, std had the correct type but libc was wrong? If this is accurate, could you submit a PR here fixing that?

I've added new module for that system in my libc fork, because libc does not have support for that system. In that module I've defined c_char as i8. Then I re-exported network related things from bsd module by specifying #[path = "..."] over submodule with dummy name and then pub use-ing everything from it. I don't think this is the right way to add new platforms, but it works fine if every c_<type> is used from crate root.

core crate thinks it is bare metal arm target and core::ffi::c_char = i8, it matched system's one, but it's just a coincidence :)