This is a discussion on Re: Sockets windows 64 bit - Openssl ; >>> Windows SOCKET is a handler to *kernel* object and as such >>> constitutes an *offset* in per-process handle table. As this >>> table can accommodate not more than 2^24 entries, it's always >>> *safe* to cast/truncate SOCKET to 32-bit ...
>>> Windows SOCKET is a handler to *kernel* object and as such
>>> constitutes an *offset* in per-process handle table. As this
>>> table can accommodate not more than 2^24 entries, it's always
>>> *safe* to cast/truncate SOCKET to 32-bit value and back. Even on
>>> 64-bit Windows.
>> for reference,
> This says that there can be no more than 2^24 entries per process,
> but it doesn't say that the value of the handle cannot exceed 2^24.
The fact that handle is *index* in a table [which is described in
Windows Internals by Russinovich and Solomon] means that values are
densely packed, and not 2^24 values wildly spread all around. One would
normally expect that they fit in 24 bit, but Windows allow for 2 *least*
significant bits to be used for application specific purposes (can't
find reference), so that value of handle to kernel object fits in 26 bits.
> Windows could, for example, use the high bits to indicate what type
> of handle it is. (Or might in a future version of Windows, causing
> applications that truncate handles to suddenly find they're not as
> portable as expected.)
Well, it doesn't and I find it hard to believe it will [kernel knows
better and shall not rely on it in either case, there is no reason to
expose it to user-land]. Secondly, 64-bit Windows allows for 64-bit
application to be executed in none "largeaddressaware" mode. This is to
allow for legacy code which interchangeably uses pointer and 32-bit
integer to be recompiled unmodified for 64-bit ISA and be executed
without risking data corruption. So even if it would use some kind of
decoration, it would be limited to 32-bit anyway [to enable legacy code
to generate revenue, as *they* would put it].
> For example, I don't see any reason an LSP couldn't use the high bits
> of a SOCKET handle to store some information which it strips off
> before it passes the SOCKET value to the underlying kernel code.
> Winsock explicitly supports user-level code between the Winsock
> functions and the kernel.
LSP is not involved in all socket I/O, most notably not if application
uses [Read|Write]File. LSP is expected to be programmed with this in
mind and therefore can't rely on such decoration [nor substitute SOCKET
with a pointer to user-land object].
> Does Microsoft actually specify somewhere that the integer value of a
> handle cannot exceed 2^24?
Not in one sentence. A.
OpenSSL Project http://www.openssl.org
Development Mailing List firstname.lastname@example.org
Automated List Manager email@example.com