Can we have windows in_addr and friends back?

[dimbleby]

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_addr and friends? Is in_addr really 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_addr on unix and whatever the winapi equivalent is on windows.

Specifically the ones that I care about are the in_addr, in6_addr, sockaddr, sockaddr_in and sockaddr_in6.

[alexcrichton]

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.

[dimbleby]

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_INET and AF_INET6 to the list of things that my code actually cares about).

[alexcrichton]

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.

[dimbleby]

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 Ipv4Addr and so on...?

[alexcrichton]

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).

[alexcrichton]

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.