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.

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

Request: place type aliases in their own module. #1820

Closed
Lokathor opened this issue Jul 10, 2020 · 8 comments
Closed

Request: place type aliases in their own module. #1820

Lokathor opened this issue Jul 10, 2020 · 8 comments

Comments

@Lokathor
Copy link

It would be handy if projects could import just the c types.

I propose that the c types be placed in their own module and then (to avoid breaking anyone) they also be publicly re-exported at the crate root. That way people who need just the types can glob import libc::ctypes::* (or whatever module name).

@ryankurte
Copy link

ryankurte commented Jul 13, 2020

yeah this would be excellent. i believe there is already work around moving these types into a module and including base definitions so they are available for all targets, as currently libc has to be substituted for cty on most of no_std platforms.

see: japaric/cty#14 and #1286

@Lokathor
Copy link
Author

(I actually also have a crate that just provides the C types, though I'm its only user :P )

@LunarLambda
Copy link

Has there been any progress on this? I'd be greatly in favour of having something like libc::types available.

I suppose there may be questions about what to include? Just C standard types, or would things like struct stat be included too?
As well as, should this be its own crate since there are undoubtedly people who want "just the types, please"

@Lokathor
Copy link
Author

Lokathor commented Aug 9, 2020

Yes, you can use the cty crate.

@joshtriplett
Copy link
Member

rust has exported these from std::os::raw::* for a while now. I'd love to see that exported from core as well. The last time types needed to move from libc to the Rust standard library, it was incredibly disruptive. Let's not go through that again, if we can put them directly in core to begin with this time.

@Lokathor
Copy link
Author

Lokathor commented Oct 7, 2020

Actually, minor nit, std::os::raw has its own definitions, not re-exported libc or cty definitions, so there could be a divergence and I'm not sure what the stability rule there is if a divergence does happen.

@joshtriplett
Copy link
Member

joshtriplett commented Oct 7, 2020 via email

@tgross35
Copy link
Contributor

With core::ffi we have the primitive types available in Rust, and Chris added a test recently that they are the same #3616. I think we can close this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants