fix fd_in_limits test on Windows

[stevengj]

Closes #52506.

OS_HANDLE on Windows is an alias for WindowsRawSocket, so I looked at the win32 socket documentation, which says that a socket handle "may take any value in the range 0 to INVALID_SOCKET–1." The INVALID_SOCKET is defined as ~0, i.e. 0xffffffff.

But I'm not 100% sure the socket docs apply here? @vtjnash's comment said it should be "in typemax(DWORD)" (== typemax(UInt32)), which would correspond to 0xffffffff and not 0xffffffff - 1. But I can't find clear docs on the value of a HANDLE — if it is really just a pointer, couldn't it be just about anything? (The old code corresponds to typemax(Int16) == 0x7fff, which suggests changing it to typemax(Int32) == 0x7fffffff, but I'm not sure where that is coming from either.) Is there a relevant section of the Win32 docs I should be looking at?

Note that this test dates back to #26341 by @vtjnash.

[stevengj]

(Even on Unix, having a test for a file descriptor in a "reasonable range" kind of scares me. Should we just delete this test entirely? It's already disabled on Macs. Or should we restrict the test failure to values that are strictly invalid, i.e. excluding only negative file descriptors on Unix?)

[vtjnash]

I am not certain where the typemax(Int16) came from there. The typemax(Int32) comes from the (undocumented) fact that the kernel observably internally truncates these handles to 32 bits, and just ignores the high bits, but really it should be legal to treat it as a signed value as well, so it is typemax(Int32) not typemax(UInt32)-1

[stevengj]

but really it should be legal to treat it as a signed value as well, so it is typemax(Int32) not typemax(UInt32)-1

Why are negative values not allowed?

[vtjnash]

I think the kernel uses those for error codes, but also just because they can be unexpected to encounter, so the kernel probably avoids them.

[stevengj]

Okay, I’ve changed it to typemax(Int32).

(It’s weird that this doesn’t seem to be documented anywhere.)

[stevengj]

Wow, green CI!

[stevengj]

merge?

[vtjnash]

Actually, I cannot conclusively prove the kernel avoids negative values, though I would still think the kernel developers would be crazy to allocate them. The limitation on having code use comparisons with < 0 or == -1, as would generally be standard on unix, doesn't work on Win32 because the type there is defined as being unsigned. Awkwardly, as some links point out, the kernel API is a bit of a mess, it is the special value 0 or NULL that is actually the one that is returned in half of functions as the invalid value and is actually invalid, while -1 is actually the bit pattern of the valid handle known as INVALID_HANDLE_VALUE, INVALID_SOCKET, but is also the valid pseudo-handle for the current window / current process / current thread among others.

And I have noticed that the kernel internally truncates the argument value handles, which seems certainly also an undocumented behavior.