Signed vs. unsigned flags types in winsock2 APIs

[sunfishcode]

Receive flag values such as MSG_WAITALL have type u32.

The flags argument of the recv function it's meant to be passed to has type i32.

send's flags argument has a dedicated type for its flags parameter called SEND_FLAGS. SEND_FLAGS is a u32.

The doc links above reference the latest version of windows-sys, which as of this post is 0.34.0.

In the POSIX specifications for send and recv, as well as the send and recv functions on all popular
Unix-family platforms, the flags argument is int, which is i32 in practice. And in winapi it's i32 as well.

In light of the above, the following would make the API more convenient:

• The recv flag values should have the same type as the recv's flags parameter so that the can be passed in without casting.
• send's and recv's flags parameters should have the same type as it does on Unix-family platforms, to make it easier to write portable code.

[riverar]

Transferring to win32metadata.

[mikebattista]

So you'd prefer we remove the SEND_FLAGS enum and just use i32 constants for both send and recv, rather than introduce RECV_FLAGS and switch both enums to i32?

[riverar]

I'd keep the enums and just ensure they are both i32 so no casting is necessary. (Note that the MSG_OOB flag is used by both APIs.)

[mikebattista]

We can't have members with the same name across enums or that will also cause problems particularly for Rust. We probably need to keep loose constants here if some values are shared across both.

[riverar]

Had a chat with @kennykerr and we settled on merging the two enums into a SEND_RECV_FLAGS enum.

[mikebattista]

If that works for everybody, we can do that.

[kennykerr]

0.36.0 of the windows crate has been released and includes this fix.