In article <keoxw1cdrwjs.2hi280n7hudh.dlg@40tude.net>, Derek Parnell says...

>Windows API assumes that no valid pointer will ever point anywhere in the range of addresses 0x00000000 to 0x0000001F, and 0xFFFFFFFD to 0xFFFFFFFF.

<more_trivia>
Actually, Win32 assumes that the range 0x00000000 to 0x0000FFFF is never valid
memory, and thus is never referenced. This is what enables the MAKEINTRESOURCE
hack.
</more_trivia>

In article <1ri252j8s1xuw.1in47u3z42esx.dlg@40tude.net>, Derek Parnell says...
>

>Actually it turns out that the term "handle" can refer to at least two types of data items. One, as you say, is a theoretically arbitrary value but is usually an index into any array, and the other is a pointer to a pointer.

I think your definition of "handle" is too restrictive. A "handle" is just an
'opaque' value used to reference an object, in the context of a library.
A handle can be 'implemented' as a pointer, a pointer to a pointer, an index
into an array, or any other way you can imagine. A different thing is how the
handle value is seen by the programmer.
Win32 handles are declared as (void*), but the fact is that it isn't documented
how exactly they are implemented.
Of course, we can guess, I have done some investigation :-)
* Some are direct pointers: HMENU, HACCEL, HINSTANCE, HANDLE from FindFirstFile
* Some are pointers to pointers: HGLOBAL
* Some are indexes into an array: SOCKET?
* Some are pointers into the address space of 'another' process: HWND
* Some are pointers into the kernel space: HANDLE of kernel objects

What I am trying to say is that the last two of them are *not* valid pointers in
the current address space, even when they are cast to void*. And so they can
theoretically trash the GC.
Of course, don't trust the list above if you want to be minimally portable,
because this is totally undocumented.
So, to be in the safe side, just say no to pointer handles.

> * Some are direct pointers: HMENU, HACCEL, HINSTANCE, HANDLE from
> FindFirstFile
> * Some are pointers to pointers: HGLOBAL
> * Some are indexes into an array: SOCKET?
> * Some are pointers into the address space of 'another' process: HWND
> * Some are pointers into the kernel space: HANDLE of kernel objects
>
> What I am trying to say is that the last two of them are *not* valid
> pointers in
> the current address space, even when they are cast to void*. And so they
> can
> theoretically trash the GC.

Only invalid pointers into the GC regions can "trash" the GC (I put quotes around trash because the GC won't get trashed but your fake pointer might). The GC knows what memory regions it owns and if a pointer points to something outside its control it ignores it. So pointing out of the address space is ok - as are values like (HANDLE)-1 that will never point to a valid GC region.

> Of course, don't trust the list above if you want to be minimally
> portable,
> because this is totally undocumented.
> So, to be in the safe side, just say no to pointer handles.

pinzo wrote:


> What I am trying to say is that the last two of them are *not* valid pointers in
> the current address space, even when they are cast to void*. And so they can
> theoretically trash the GC.

Since they are not GC-allocated resources, how are they going to trash the DC? From the GC docs:

"Pointers in D can be broadly divided into two categories: those that point to garbage collected memory, and those that do not. Examples of the latter are pointers created by calls to C's malloc(), pointers received from C library routines, pointers to static data, pointers to objects on the stack, etc. For those pointers, anything that is legal in C can be done with them."

The two points you began the thread with apply to GCed pointers, which Win32 HANDLES are not.

In article <df9e92$e1a$1@digitaldaemon.com>, Mike Parker says...
>
>pinzo wrote:
>
>> What I am trying to say is that the last two of them are *not* valid pointers in the current address space, even when they are cast to void*. And so they can theoretically trash the GC.
>
>Since they are not GC-allocated resources, how are they going to trash the DC? From the GC docs:
>
>"Pointers in D can be broadly divided into two categories: those that point to garbage collected memory, and those that do not. Examples of the latter are pointers created by calls to C's malloc(), pointers received from C library routines, pointers to static data, pointers to objects on the stack, etc. For those pointers, anything that is legal in C can be done with them."
>
>The two points you began the thread with apply to GCed pointers, which Win32 HANDLES are not.

With the current mark/scan implementation, the worst that could happen is memory not being recycled when it should be (because the GC mistakes a handle value for a pointer into GC memory).  With a generational (ie. copying) GC, the handle value could be changed if it happens to coincide with the address of a valid GC memory block.


Sean

On Sat, 03 Sep 2005 02:03:43 +0200, Sean Kelly <sean@f4.ca> wrote:

> In article <df9e92$e1a$1@digitaldaemon.com>, Mike Parker says...
> With the current mark/scan implementation, the worst that could happen is memory
> not being recycled when it should be (because the GC mistakes a handle value for
> a pointer into GC memory).  With a generational (ie. copying) GC, the handle
> value could be changed if it happens to coincide with the address of a valid GC
> memory block.

Well, to be on the safe side of the life, I strongly suggest to change all handle
types to size_t or similar, the cost of this change is practically zero, and
the potential problems and incompatibilities that can arise with this or future
GC implementations are too great.

On Sun, 04 Sep 2005 23:30:42 +0200, <rodrigorivascosta@gmail.com> wrote:

> Well, to be on the safe side of the life, I strongly suggest to change all handle
> types to size_t or similar, the cost of this change is practically zero, and
> the potential problems and incompatibilities that can arise with this or future
> GC implementations are too great.

I have just messed up my newsreader program. That was myself, of course.

---

Pinzo.

"pinzo" <pinzo_member@pathlink.com> wrote in message news:df8pve$2nfe$1@digitaldaemon.com...
> What I am trying to say is that the last two of them are *not* valid
pointers in
> the current address space, even when they are cast to void*.

That's true.

> And so they can
> theoretically trash the GC.

In the case of Windows handles, that's not likely because the only values that can trash the GC are values that happen to fall within range of the GC's allocated memory pool. The non-pointer values I've seen in Windows handles are all less than 64K, which is never, by design, memory allocated to a process, hence cannot point into the GC pool.

> Of course, don't trust the list above if you want to be minimally
portable,
> because this is totally undocumented.
> So, to be in the safe side, just say no to pointer handles.

For any new design, that is correct. You can do a legacy special case exception for Windows handles, though.

"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:df880n$25p2$1@digitaldaemon.com...
> In Win32 API HANDLE is void* but there are places where things like -1 are cast to HANDLE. I'm not aware of what non-pointers are cast to HANDLES but I've never looked into it. The "pointer to pointer" is what Macs used ages ago and from what I understand the Mac OS X doesn't use handles anymore.
In
> MATLAB, ironically, a handle is a double :-) That's because back when
MATLAB
> first got graphics objects (called Handle Graphics) the double was the
only
> datatype in MATLAB. It has advantages and disadvantages but I'm mentioning it just for those trivia-minded folks out there who are interested in uses of the word "handle".

16 bit DMC++ supports a "handle" pointer type, which is the combination of an EMM page number, and EMM page offset. A runtime conversion would be done automagically to map the EMM page into memory and then compute an actual pointer into it.

char __handle *p;

Ah, those were the daze <g>.

"Derek Parnell" <derek@psych.ward> wrote in message news:akshp04hduz4$.16z4tpc4g2lzg$.dlg@40tude.net...
> This usage was extensively used in the Amiga system too. In the Amiga, there was only one fixed address in the entire system. The address 0x00000004 contained the address of where the core library was loaded into RAM. From that knowledge, you could locate everything else in the system. They chose that address instead of zero because a common mistake for
coders
> was to write something to RAM using a null pointer and doing that would have wiped out the operating system :D

The biggest mistake in the Intel 8088 design was to put the interrupt table in the bottom 64Kb of memory, guaranteeing that any NULL or offset-from-NULL pointer write would trash the operating system. This means that EVERY time your program crashed, the only thing to do was reboot regardless, otherwise you risked scrambling your hard disk.

The system PROM should have been mapped to the bottom 64Kb (instead of the
top 64Kb).

The biggest productivity booster for the old DOS days was when OS/2 1.1 came out, which ran 16 bit programs in protected mode. Oh heaven, a program could crash and I didn't have to reboot! I never did develop on DOS after that - all the programs were built, debugged, and tested on OS/2 1.1, and only the last step was getting them running under DOS.