On Tue, Nov 16, 2010 at 16:23, Tom Lane <t...@sss.pgh.pa.us> wrote: > Magnus Hagander <mag...@hagander.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.
I think it is pretty clear it does - the section has a list of different handles at the bottom. What we're using is a File Mapping Object, which is not on that list. And which is, AFAICT, not a user or gdi handle. That doesn't mean it's not guaranteed to be in the 32-bit space, but I'm pretty sure that specific page doesn't guarantee it. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
