Windows SOCKET type defined inconsistently between libc vs std::os::windows

[infinity0]

• https://github.com/rust-lang/rust/blob/master/library/std/src/sys/windows/ext/raw.rs says u32/u64
• https://github.com/rust-lang/libc/blob/master/src/windows/mod.rs#L51 says uintptr_t aka usize

For some reason official MS SDK docs likes to keep the actual definition a secret

• https://github.com/mirror/mingw-w64/blob/master/mingw-w64-headers/include/psdk_inc/_socket_types.h says uintptr_t
• http://www.novell.com/documentation/developer/samplecode/ndpscomp_sample/gateway_inc/WINSOCK2.H.html says u_int/uintptr_t

Probably the std definition should be changed to usize to match the libc crate.

[mati865]

From MSVC headers:

$ rg "SOCKET;" '/d/Program Files (x86)/Windows Kits/10/Include/10.0.18362.0'
D:/Program Files (x86)/Windows Kits/10/Include/10.0.18362.0\um\winsock.h
51:typedef UINT_PTR        SOCKET;

D:/Program Files (x86)/Windows Kits/10/Include/10.0.18362.0\um\WinSock2.h
122:typedef UINT_PTR        SOCKET;

Unfortunately this would be breaking change since that type is public.

[infinity0]

The types have the same representation, so I imagine if anyone is converting between the two (std vs libc) they are already using try_into which is what the current rustc error message recommends.

Otherwise, any code that depends on the current incorrect definition (being identical to u32/u64) should be fixed anyway.

[retep998]

From what I remember back when winapi was switching from u32/u64 to usize, it was the breaking change risk that stopped std from changing this definition. I'd love if it could be fixed.

Is crater able to actually test Windows specific changes like this yet?

[infinity0]

Since rust is a young language, I'd say that breaking some old incorrectly-written code is better than forcing all future as-yet-unwritten code to contain pointless workarounds like try_into.

[tesuji]

Could we land the changing type and revert it back to get a working compiler for testing ?

I changed the type definition locally (8ec8939a3e11fa4953639b6794db5ecb33b444ad) and ./x.py check --stage 2 --host x86_64-pc-windows-gnu --target x86_64-pc-windows-gnu (I'm on x86_64-unknown-linux-gnu) succeeded. It seems that the compiler itself can be built sucessfully with the change.

[recatek]

It looks like Rust's std::os::windows::raw::SOCKET type is defined as

#[cfg(target_pointer_width = "32")]
#[doc(cfg(all()))]
#[stable(feature = "raw_ext", since = "1.1.0")]
pub type SOCKET = u32;
#[cfg(target_pointer_width = "64")]
#[doc(cfg(all()))]
#[stable(feature = "raw_ext", since = "1.1.0")]
pub type SOCKET = u64;

Would it make more sense for this to be a usize? The equivalent windows_sys::Win32::Networking::WinSock::SOCKET in the first-party Windows crate uses a usize.

[ChrisDenton]

Making a breaking change like this would require a crater run (that's where we test all the code on crates.io and open source code on GitHub). Unfortunately all our runners are for Linux, not Windows.

[recatek]

Linking this to rust-lang/crater#149 in that case.