-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Comments
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 see: japaric/cty#14 and #1286 |
(I actually also have a crate that just provides the C types, though I'm its only user :P ) |
Has there been any progress on this? I'd be greatly in favour of having something like I suppose there may be questions about what to include? Just C standard types, or would things like |
Yes, you can use the |
rust has exported these from |
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. |
On Tue, Oct 06, 2020 at 06:00:21PM -0700, Lokathor wrote:
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.
Huh. For some reason I had thought that libc re-exported the definitions
from `std::os::raw`, but it looks like libc only does so for `c_void`.
|
With |
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).The text was updated successfully, but these errors were encountered: