Re: Isn't HANDLE 64 bits on Win64?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, Dave Page <dpage(at)pgadmin(dot)org>
Subject: Re: Isn't HANDLE 64 bits on Win64?
Date: 2010-11-16 15:23:50
Message-ID: 28438.1289921030@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> Do you still have a reference to the page that said they will never be
> assigned that high?

http://msdn.microsoft.com/en-us/library/ms810720.aspx

which says

USER and GDI handles are sign extended 32b values

To facilitate the porting, a decision has been made that these system
handles should stay as 32b values, sign extended to 64b on the 64b
platform. That is, the individual handle types are still based on the
HANDLE type, which maps to void *, and so the size of the handle is the
size of the pointer, i.e. 4 bytes on 32b and 8 bytes on 64b. However,
the actual value of the handle on the 64b platform, (i.e. the meaningful
bits), fits within the lower 32b, while the upper bits just carry the
sign.

This should make it easy to port the majority of the application
code. Handling of the special values, like -1, should be fairly
transparent. It also should agree nicely with all the cases where the
handles had been remoted with the help of the IDL definitions from the
public file wtypes.idl. However, care needs to be taken when remoting
the handles was done via a DWORD, as the upper long should be properly
sign extended on the 64b side. The app should use HandleToLong() and
LongToHandle() macros (inline functions) to do the casting right.

What's not clear to me is whether the section title means that only
certain handles have this guarantee, and if so whether we have to worry
about running into ones that don't.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2010-11-16 15:24:42 Re: track_functions default
Previous Message Tom Lane 2010-11-16 15:16:49 Re: GCC vs clang