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

Re-export c_void from std::os::raw #71

Closed
wants to merge 1 commit into from

Conversation

SimonSapin
Copy link
Contributor

This avoid silly errors like:

error: mismatched types:
 expected `*mut libc::c_void`,
    found `*mut std::os::raw::c_void`

and should have no other effect since the two definitions were identical.

CC servo/servo#8446

This avoid silly errors like:

```
error: mismatched types:
 expected `*mut libc::c_void`,
    found `*mut std::os::raw::c_void`
```

and should have no other effect since the two definitions were identical.
@SimonSapin
Copy link
Contributor Author

Where I’m at it, should everything else from std::os::raw be re-exported as well? It’s less important for type aliases than custom enums, but in case they ever get out of sync again (rust-lang/rust#29867)

@alexcrichton
Copy link
Member

The CI is failing here for the reason actually for why this was not done in the first place. I explained a bit more in #59 and this was also mentioned in the RFC, but for now this is intentional, so closing.

SimonSapin added a commit to SimonSapin/rust that referenced this pull request Nov 22, 2015
… and re-export at the old location.

This is primarily motivated by rust-lang/libc#71
(to support src/liblibc), but also because why not.
@SimonSapin
Copy link
Contributor Author

This is causing so much pain :(

@SimonSapin
Copy link
Contributor Author

I’ve been fighting with the same error all over the place for days:

 expected `*const std::os::raw::c_void`,
    found `*const libc::c_void`

@alexcrichton
Copy link
Member

Can you elaborate on why that's coming up? That sounds like some dependencies started transitioning to using std's c_void while others are still using libc and they're getting mixed up?

@SimonSapin
Copy link
Contributor Author

Yes, exactly. And this is happening across dozens of crates and repositories. Every time I update any dependency, I end up sending lots of PRs to fix precisely this error, sometimes by changing nothing but a version number in Cargo.toml.

@alexcrichton
Copy link
Member

How does changing a version fix things? Both 0.1 and 0.2 define c_void, so I'm not sure how that'd get the types to align. Is that because some dependencies have updated to using the std c_void and older versions are using the libc c_void?

@SimonSapin
Copy link
Contributor Author

For example, library A has a public function that takes a *const libc::c_void parameter and upgrades from libc 0.1 to 0.2. Library B depends on library A and calls that function with a pointer that comes from somewhere that still uses libc 0.1. In this case you’d get a build error that is fixed simply by changing a version number in B’s Cargo.toml. (Similar story with std::os::raw instead of libc 0.2) Repeat with dozens of libraries in a dense dependency graph.

It’s frustrating because the exact definition of c_void is as uninteresting as it gets. As far as I can tell, it could be pub type c_void = ();. Some projects do just that: PistonDevelopers/piston#1000, Rust-SDL2/rust-sdl2#465.

If c_void was a type alias like c_int with the same definition in three places, these build errors would not exist in the first place. But three identical enums are different types.

Anyway, now that libc 0.1 and 0.2 are as they are I don’t have a solution to propose that would help here. I’m mostly just ranting to vent frustration, sorry.

@SimonSapin
Copy link
Contributor Author

@alexcrichton Are you still opposed to this? The reason you linked to above says “In order to have maximal compatibility with all Rust versions”. std::os::raw::c_void was stabilized in Rust 1.1.0. Is it time yet to let go of compatibility with Rust 1.0.0 ?

@alexcrichton
Copy link
Member

Yes I would still be opposed to this. This doesn't make sense when libc's default mode of operation is no_std, which it should be.

The discussion about c_void specifically is broad and far reaching, I'd recommend reading https://internals.rust-lang.org/t/solve-std-os-raw-c-void/3268

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

Successfully merging this pull request may close these issues.

None yet

2 participants