std: net: Add function to return the system hostname by orowith2os · Pull Request #135141 · rust-lang/rust

orowith2os · 2025-01-06T00:10:05Z

Resolves rust-lang/libs-team#330
Tracking issue: #135142

Now you can retrieve the system hostname, without relying on anything other than std!

This is my first pull request to the Rust standard library (or anything inside rust-lang/rust, period, quite possible rust-lang itself), so there are bound to be issues. I'll try my best to resolve them.

rustbot · 2025-01-06T00:10:13Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @joboet (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

@rustbot author: the review is finished, PR author should check the comments and take action accordingly
@rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

library/std/src/net/hostname.rs

library/std/src/net/mod.rs

orowith2os · 2025-01-06T01:03:33Z

forgive all the updates, I was having troubles updating my branch properly. Figured it out.

orowith2os · 2025-01-16T19:58:35Z

Sorry for that last push - I updated the doc comment on gethostname to specify when it should be able to error out, so it's not just a black box.

joboet · 2025-01-17T13:40:15Z

Right, that covers most platforms. Some targets are still missing, though (to find these I basically went through the directories in sys/pal and looked for platforms with a net module):

wasm32-wasip1 and wasm32-wasip2 (tier 2)
x86_64-fortanix-unknown-sgx (tier 2)
aarch64-kmc-solid_asp3 (tier 3)
riscv32imac-unknown-xous-elf (tier 3)
x86_64-unknown-hermit (tier 3)

joshtriplett · 2025-01-17T14:29:04Z

DNS names can only be ASCII, but hostnames are not just DNS names. I've seen hostnames for phones and computers that have Unicode characters in them, and I would be unsurprised to discover hostnames that use local character sets.

That said, if we define this to be a form of hostname that works as a valid DNS component, then 👍 for making it String.

orowith2os · 2025-01-17T15:07:22Z

@joboet would it be fine to mark them as TODO in the tracking issue?

joboet · 2025-01-17T15:20:16Z

@joboet would it be fine to mark them as TODO in the tracking issue?

For the tier 3 targets, yeah that's fine. The tier 2 targets are built in the merge CI, so they'll need to compile (stubbing the function out is fine).

joboet · 2025-01-21T12:44:01Z

DNS names can only be ASCII, but hostnames are not just DNS names. I've seen hostnames for phones and computers that have Unicode characters in them, and I would be unsurprised to discover hostnames that use local character sets.

That said, if we define this to be a form of hostname that works as a valid DNS component, then 👍 for making it String.

T-libs-api, what do you think? I think this should be clarified before merging, since OsString is not the correct output type on Windows – gethostname can return any bytes, whereas OsString must be correct WTF-8, so it either can't represent all possible outputs or can hold too many outputs, depending on whether you consider non-ASCII hostnames to be invalid.

@rustbot label +I-libs-api-nominated

Amanieu · 2025-01-21T16:42:46Z

We discussed this in the libs-api meeting: on Windows this should call GetHostByNameW to get a UTF-16 string, which can then be converted to an OsString.

orowith2os · 2025-01-21T17:01:44Z

Then I'll keep it as OsString, but I won't implement the Windows bits. I'll leave that to someone willing to pick it up.

joboet · 2025-01-24T15:13:47Z

@orowith2os I've opened orowith2os#1 on your fork and implemented the Windows bit there.

…code resilient against bad platform behaviour

joboet · 2025-01-24T15:20:51Z

I shouldn't review my own code, so
r? @ChrisDenton (you probably know best about the Windows stuff)

ChrisDenton

The code looks fine. Note though that Windows 7 doesn't have GetHostNameW so it'd need. a fallback, However, it's also tier 3 so can be left to a follow up by the target maintainer.

ChrisDenton · 2025-01-24T21:40:51Z

library/std/src/sys/pal/windows/net.rs

+    // always enough.
+    let mut buffer = [0; 256];
+    // SAFETY: these parameters specify a valid, writable region of memory.
+    let ret = unsafe { c::GetHostNameW(buffer.as_mut_ptr(), buffer.len() as i32) };


I guess my one nitpick is that maybe the max buffer len could be a constant instead of using as i32, which is often a code smell but in this case it's narrowly scoped enough that I don't feel strongly about it.

valaphee · 2025-01-27T08:03:51Z

Didn't know that there is a dedicated GetHostName function in WSA, would have expected GetComputerNameExW. Implemented since Windows 2000, and doesn't require WS2 init.

As per rust-lang#117276, this PR moves `sys_common::net` and the `sys::pal::net` into the newly created `sys::net` module. In order to support rust-lang#135141, I've moved all the current network code into a separate `connection` module, future functions like `hostname` can live in separate modules. I'll probably do a follow-up PR and clean up some of the actual code, this is mostly just a reorganization.

bors · 2025-02-06T00:59:17Z

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

ChrisDenton · 2025-02-16T16:20:16Z

This needs to be rebased but then I think it'll be good to be merged.

Dylan-DPC · 2025-08-12T19:20:53Z

@orowith2os any updates on this? this just requires a rebase and seems good to merge.

orowith2os · 2025-08-12T19:22:45Z

I don't have a dev environment available to rebase with, but if someone else wants to, go for it.

tbu- · 2025-12-11T06:40:56Z

This looks like it's superseded by #146937 and can be closed.

rustbot assigned joboet Jan 6, 2025

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jan 6, 2025