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

A feature for types only #1560

Closed
elichai opened this issue Oct 18, 2019 · 9 comments
Closed

A feature for types only #1560

elichai opened this issue Oct 18, 2019 · 9 comments

Comments

@elichai
Copy link
Contributor

elichai commented Oct 18, 2019

Hi,

Would people be in favor of a feature for only types? i.e. no function definitions, just getting all the typedefs.

This can be useful for me here rust-lang/rfcs#2610 (comment)

Although I'm still debating if I should maintain my own list of typedefs for the kernel, flags etc.

How do people feel about this?

@gnzlbg
Copy link
Contributor

gnzlbg commented Oct 18, 2019

I started working on this, but other things came in the way: #1286

@elichai
Copy link
Contributor Author

elichai commented Oct 18, 2019

I was actually thinking to also includes the flag types
i.e. F_SETFL

@gnzlbg
Copy link
Contributor

gnzlbg commented Oct 18, 2019

What problem are you trying to solve ?

@elichai
Copy link
Contributor Author

elichai commented Oct 18, 2019

I'm mostly worried i'll accidentally use an extern "C" static typess instead of a typedef.

@gnzlbg
Copy link
Contributor

gnzlbg commented Oct 18, 2019

Why can't you write a wrapper crate over libc that only re-exports what you want ?

@elichai
Copy link
Contributor Author

elichai commented Oct 18, 2019

that might be an option. but even then i'll need to always check the types i'm re-exporting are still just typedefs(or structs?) but not a link.

@gnzlbg
Copy link
Contributor

gnzlbg commented Oct 18, 2019

Sure, you'd have to do that.

I personally do not think it is worth it to introduce complexity for this in the libc crate when the motivation appears to be to implement a Rust target that does not use this crate, and once that is achieved, all this complexity wouldn't be required.

The libc crate does, however, have very strong backward compatibility guarantees, so we couldn't just remove this complexity later.

@elichai
Copy link
Contributor Author

elichai commented Oct 18, 2019

That's fair.
I can try to help with #1286 if you can point me to what missing. because I know of a bunch of crates that would like that use case.

@gnzlbg
Copy link
Contributor

gnzlbg commented Oct 18, 2019

In the mean time you can just use the cty crate from crates.io.

The issues related to that PR are more organizational than implementation-related.

(I'm closing this, but please feel free to re-open if you think there is something else we can do here)

@gnzlbg gnzlbg closed this as completed Oct 18, 2019
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

2 participants