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

Add equivalents for INADDR_ANY, INADDR_LOOPBACK to std::net #39819

Closed
luser opened this issue Feb 14, 2017 · 7 comments
Closed

Add equivalents for INADDR_ANY, INADDR_LOOPBACK to std::net #39819

luser opened this issue Feb 14, 2017 · 7 comments
Labels
C-feature-accepted Category: A feature request that has been accepted pending implementation. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@luser
Copy link
Contributor

luser commented Feb 14, 2017

POSIX defines:

  • INADDR_ANY, which is 0.0.0.0 as an in_addr
  • INADDR_BROADCAST, which is 255.255.255.255 as an in_addr
  • in6addr_any + IN6ADDR_ANY_INIT, which is the same concept as an in6_addr (with wonky variable + macro usage because structs in C are terrible)
  • in6addr_loopback + IN6ADDR_LOOPBACK_INIT, which is ::1 as an in6_addr

glibc additionally defines:

  • INADDR_LOOPBACK, which is 127.0.0.1 (I don't know why this isn't in POSIX)
  • INADDR_NONE, which is just used as an error return, so not really useful in Rust

I think it would be useful to have at least consts for the ANY + LOOPBACK values for IPv4 and IPv6 in std::net.

From cursory googling while looking up the sources above I did find a few people wondering why these were missing from the Rust standard library:
https://users.rust-lang.org/t/where-is-inaddr-any-for-std-net/2337
https://www.reddit.com/r/rust/comments/3gi34h/inaddr_any_in_rust/

@luser
Copy link
Contributor Author

luser commented Feb 14, 2017

Currently in Rust you either write these out as strings (which all the examples in std::net seem to do), like TcpStream::connect("127.0.0.1:12345"), or you call Ipv4Addr::new, like TcpStream::connect((Ipv4Addr::new(127, 0, 0, 1), 12345)). They're both a little clunky, and the former requires parsing a string to get a value that is always going to be the same.

@Mark-Simulacrum
Copy link
Member

cc @rust-lang/libs, I assume we probably want this developed out-of-tree as per usual? Probably in the net2 crate?

@Mark-Simulacrum Mark-Simulacrum added the T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. label May 23, 2017
@sfackler
Copy link
Member

These are just a couple of new consts, right? I don't see any reason to not just add them (unstable at first of course).

@Mark-Simulacrum
Copy link
Member

I believe so, though I'm uncertain. @luser Are these just a set of constants?

@luser
Copy link
Contributor Author

luser commented May 23, 2017

Yes, these are all just constants.

@Mark-Simulacrum Mark-Simulacrum added the C-feature-request Category: A feature request, i.e: not implemented / a PR. label Jul 27, 2017
@dtolnay dtolnay added C-feature-accepted Category: A feature request that has been accepted pending implementation. and removed C-feature-request Category: A feature request, i.e: not implemented / a PR. labels Nov 19, 2017
@dtolnay
Copy link
Member

dtolnay commented Nov 19, 2017

I believe we are ready to consider a PR exposing these constants.

@luser
Copy link
Contributor Author

luser commented Nov 7, 2018

@luser luser closed this as completed Nov 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-feature-accepted Category: A feature request that has been accepted pending implementation. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants