Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Create a separate libc_types crate for basic C types #1783

Closed
wants to merge 4 commits into from
Closed

Create a separate libc_types crate for basic C types #1783

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
b322ac2
Create a separate libc_types crate for basic C types
Amanieu Nov 3, 2016
ef4e3bc
Fix quote from GCC documentation
Amanieu Nov 3, 2016
55ee184
Update motivation and drawbacks
Amanieu Nov 3, 2016
85b7d3e
Add c_char
Amanieu Nov 4, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Update motivation and drawbacks
  • Loading branch information
@Amanieu
Amanieu authored Nov 3, 2016
commit 55ee1840d94d6283af7e4d6175f80f08dc961ebd
5 changes: 4 additions & 1 deletion text/0000-libc-types.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,6 +23,8 @@ A more interesting case is that of bindings for C libraries which can work in a

Finally, a separate `libc_types` crate would allow Rust on Windows to avoid linking to the MS CRT entirely. This would make Rust executables more portable since they would not require a user to install a Visual Studio redistributable package.

The types in the `libc` cannot be used in these situations because the `libc` crate will cause the resulting binary to link to the platform C library, which is undesirable.

Relevant discussions on [internals](https://internals.rust-lang.org/t/solve-std-os-raw-c-void/3268) and on [Github](https://github.com/rust-lang/rust/issues/31536).

# Detailed design
Expand Down Expand Up @@ -70,11 +72,12 @@ To preserve backward compatibility, these types will be re-exported by the `libc
# Drawbacks
[drawbacks]: #drawbacks

- Adds an additional crate to the standard library.
- Adds an additional crate to the standard library. Although users will only import this crate from crates.io, it must still be distributed as part of the standard library since it is a dependency of the `libc` crate. The version distributed with the standard library will of course be unstable and hidden behind the same feature flag as `libc`.

# Alternatives
[alternatives]: #alternatives

- Put these types in `libcore` instead. This was proposed on the internals thread, but the consensus seems to be that C FFI types do not belong in `libcore.
- Do nothing. Freestanding code will have to use standard rust types and write their own bindings for C libraries.

# Unresolved questions
Expand Down