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

Converts AddressFamily to struct with associated consts #2210

Closed
wants to merge 1 commit into from

Conversation

Jan561
Copy link
Contributor

@Jan561 Jan561 commented Nov 25, 2023

Split off from #2199

Script I used to generate the variants: https://gist.github.com/Jan561/067d64641c93017a9bf6b346ac078ec1

Checklist:

  • I have read CONTRIBUTING.md
  • I have written necessary tests and rustdoc comments
  • A change log has been added if this PR modifies nix's API

@Jan561 Jan561 force-pushed the address_families branch 2 times, most recently from 1e05db3 to d47caef Compare November 25, 2023 16:46
@Jan561
Copy link
Contributor Author

Jan561 commented Nov 25, 2023

I'll provide a changelog when rebasing on top of #2211

@Jan561
Copy link
Contributor Author

Jan561 commented Nov 30, 2023

If you want, I can just add the new variants to the enum for the time being, and postpone the breaking changes

Copy link
Member

@asomers asomers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is pretty intrusive change. Could you please explain the justification in more detail?

Comment on lines +89 to +92
apple_targets,
freebsdlike,
linux_android,
netbsdlike,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
apple_targets,
freebsdlike,
linux_android,
netbsdlike,
bsd,
linux_android,

@@ -351,7 +552,7 @@ impl UnixAddr {
pub fn new<P: ?Sized + NixPath>(path: &P) -> Result<UnixAddr> {
path.with_nix_path(|cstr| unsafe {
let mut ret = libc::sockaddr_un {
sun_family: AddressFamily::Unix as sa_family_t,
sun_family: AddressFamily::UNIX.family() as sa_family_t,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should AddressFamily implement Into<sa_family_t>?


/// Address families, corresponding to `AF_*` constants in libc.
#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
pub struct AddressFamily(libc::c_int);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All Newtypes should use repr(transparent). You might even be able to cast directrly from AddressFamily to other int types just by using as, instead of .family().

Suggested change
pub struct AddressFamily(libc::c_int);
#[repr(transparent)]
pub struct AddressFamily(libc::c_int);

}

/// Returns the c_int representation of the address family.
pub const fn family(&self) -> libc::c_int {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method is confusingly named, since Self is already a "family". Better would be to implement Something like Into<libc::c_int>.

@@ -689,7 +689,7 @@ pub enum ControlMessageOwned {
/// // Set up
/// let message = "Ohayō!".as_bytes();
/// let in_socket = socket(
/// AddressFamily::Inet,
/// AddressFamily::INET,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All of these capitalization changes would be a burden on our users. It would be much more convenient if we didn't change it.

@Jan561
Copy link
Contributor Author

Jan561 commented Dec 4, 2023

This is pretty intrusive change. Could you please explain the justification in more detail?

It should've been a struct with associated constants from the beginning.

At least theoretically. I won't ever need vendor address families personally, as well as 99.9% of nix users. So yeah, the practical impact of this PR as is would be very low.

That's why I was suggesting to change the PR to only add new variants to the enum (I only need to change one line of my script).

But before hitting 1.0 (in the very distant future), I would definitely reconsider the current enum API.

@Jan561 Jan561 closed this Apr 11, 2024
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.

2 participants