type change for AF_INET, PF_INET AF_INET6 PF_INET6

[sum12]

I am not sure if this change is enough or more is needed fo #468

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @JohnTitor (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[bors]

☔ The latest upstream changes (presumably #1793) made this pull request unmergeable. Please resolve the merge conflicts.

[JohnTitor]

Hey, thanks for the PR! But this is a breaking change, as Alex said, and I'd hold off this as we currently have no plan to make a release 0.3 or 1.0.

[sum12]

ok. Thanks for taking a look.
Any other ways I could contribute ?

[JohnTitor]

Any other ways I could contribute ?

Basically we add items when we need them. There're some requests on the issue tracker that someone wants to use constants or functions, I think they're good stuff to contribute (btw, if you want to contribute to Rust, there're some repos like rust-lang/rust that have more newcomer welcome issues).

[bors]

☔ The latest upstream changes (presumably #1962) made this pull request unmergeable. Please resolve the merge conflicts.

Note that reviewers usually do not review pull requests until merge conflicts are resolved! Once you resolve the conflicts, you should change the labels applied by bors to indicate that your PR is ready for review. Post this as a comment to change the labels:

@rustbot modify labels: +S-waiting-on-review -S-waiting-on-author

[joshtriplett]

Even if we were making breaking changes, I don't think we'd want to change the types of these particular constants and not others in the same category.

In C, these are preprocessor symbols, and they don't have a type. I don't think this kind of change is worth the breakage it would cause.

[safinaskar]

Now this can be resent to libc 0.3