Repository navigation
Can we have windows in_addr and friends back? #45
Description
Activity
Currently these types are also provided by
winapi(under mostly the same names), although I'd certainly believe that the experience is unfortunately a little painful!Currently the scope of this library is just the CRT bindings, which I don't think includes these networking primitives, but it could be possible to perhaps expand the scope.
I can see that "the CRT bindings" is a temptingly clean place at which to draw the line.
However, I'd argue that a more helpful approach would be: if it sensibly can be cross-platform, then make it cross-platform.
That is: if I could write C code using structure X (or value Y) and reasonably expect that such code would compile cross-platform - well then structure X (or value Y) should be available in Rust's
libc.I realise that where I write "sensibly", and "reasonably expect", I'm asking that someone make a judgement call; and that this is more difficult than defining a hard rule and sticking with it. But I'd propose that "being useful to people writing Rust" is a better guideline than "it depends on which header files Microsoft chose to put something in". So I'd favour expanding the scope of this library, where doing so meets that goal.
(Philosophy aside, I've noticed while writing this that I would like to add
AF_INETandAF_INET6to the list of things that my code actually cares about).Yeah it's true that drawing the line at the CRT is somewhat arbitrary, and this would certainly perhaps be useful to have!
I'm a little worried about feature creep here in the sense of what's the new line? Anything that happens to be defined on "most unix platforms" as well as Windows? That may end up working out in practice, but there's definitely pros and cons to having a hard line.
Yep, agreed - though I'd hope that the particular things that I'm asking for in this issue lie towards the uncontroversial end of the spectrum.
Indeed, isn't Rust's own standard library going to want these structures for its implementation of
Ipv4Addrand so on...?For an implementation detail, yeah, but for now we end up just defining everything on Windows ourselves (although in the future we'd like to use the winapi set of crates for this).
The libs team discussed this during triage today and the decision was to hold the line for now at the CRT on Windows. We can always add these at a later date if it becomes necessary but for now using winapi + libc is the way to go.
- added a commit that references this issue
on Feb 22, 2025 - added a commit that references this issue
on Apr 2, 2025
c4d4c70 removed a bunch of Windows-specific stuff, the view presumably being that it all better belonged in
winapi.Did this overshoot, though, in removing
in_addrand friends? Isin_addrreally a Windows-specific API?For those of us trying to write cross-platform low-level code it's a right pain to have to deal with a
libc::in_addron unix and whatever thewinapiequivalent is on windows.Specifically the ones that I care about are the
in_addr,in6_addr,sockaddr,sockaddr_inandsockaddr_in6.