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

Better factoring for flags code #513

Open
sunfishcode opened this issue Jan 13, 2023 · 2 comments
Open

Better factoring for flags code #513

sunfishcode opened this issue Jan 13, 2023 · 2 comments

Comments

@sunfishcode
Copy link
Member

sunfishcode commented Jan 13, 2023

Rustix has this pattern where it defines flags types in both src/backend/linux_raw/*/types.rs and src/backend/libc/*/types.rs and then publicly exports those types from src/*/*.rs. This leads to a fair amount of duplication.

In many cases, espeically for flags corresponding to Linux-specific features, it would work to just define the public type in src/*/*.rs using the values of c::* constants which we could arrange to be defined by both backends, and it'd have less overall duplication.

It'd be nice to factor out the flags values in this way.

@sunfishcode
Copy link
Member Author

This will also involve eliminating some differences in types between the backends, where currently the linux_raw backend uses u32 for many of its flags types due to how bindgen works, and the libc backend uses i32 due to how C works.

@sunfishcode sunfishcode mentioned this issue Mar 29, 2023
17 tasks
@sunfishcode sunfishcode added semver bump Issues that will require a semver-incompatible fix and removed semver bump Issues that will require a semver-incompatible fix labels Jun 17, 2023
@sunfishcode
Copy link
Member Author

As of #701, the libc branch uses u32 for flags types. Some of the common code for flags is factored out, though there's more to do, though now, it won't require a semver bump.

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

1 participant