Hello all.
I have just read through the docs and found this statements regarding the GC:
 * Do not store into pointers values that may point into the garbage collected heap.
 * Do not store magic values into pointers, other than null.

But now, looking at std.c.windows.windows I noticed that Win32 HANDLEs (that is HANDLE, HWND, HFILE, etc) are defined:

alias void* HANDLE;

Since HANDLEs are just arbitrary values, and usually don't even point to user memory, won't that raise undefined behavior.

If it's true, I think that just changing the definition to something like:

typedef size_t HANDLE;

would do the trick, since size_t should have the same size and alignment requirements that a pointer.

What do you think?

pinzo@gmail.com wrote:
> Hello all.
> I have just read through the docs and found this statements regarding the  GC:
>  * Do not store into pointers values that may point into the garbage  collected heap.
>  * Do not store magic values into pointers, other than null.
> 
> But now, looking at std.c.windows.windows I noticed that Win32 HANDLEs  (that is HANDLE, HWND, HFILE, etc) are defined:
> 
> alias void* HANDLE;
> 
> Since HANDLEs are just arbitrary values, and usually don't even point to  user memory, won't that raise undefined behavior.

Presumably, going by the spec docs you quoted.

> If it's true, I think that just changing the definition to something like:
> 
> typedef size_t HANDLE;
> 
> would do the trick, since size_t should have the same size and alignment  requirements that a pointer.
> 
> What do you think?

I think you've got the right idea, except I might debate the merits of using 'typedef' over 'alias' in this case, and I'd probably use 'ptrdiff_t' rather than 'size_t'.

-- Chris Sauls

Storing pointers to non-GC data is fine (ie malloc'ed data or HANDLES). What you don't want to do is store an arbitrary value into a pointer type since it might accidentally point to some GC region.

<pinzo@gmail.com> wrote in message news:op.swfmpvdn0r3bey@pinzopc2...
Hello all.
I have just read through the docs and found this statements regarding the
GC:
  * Do not store into pointers values that may point into the garbage
collected heap.
  * Do not store magic values into pointers, other than null.

On Thu, 01 Sep 2005 22:37:56 +0200, Ben Hinkle <bhinkle@mathworks.com> wrote:

> Storing pointers to non-GC data is fine (ie malloc'ed data or HANDLES). What
> you don't want to do is store an arbitrary value into a pointer type since
> it might accidentally point to some GC region.

The problem here is that HANDLE values, in general, are not pointers! They are arbitrary values
cast to (void*) (well, maybe pointers from kernel space or from CSRSS space, etc.)
So they could point just anywhere, including GC-data.

On Thu, 01 Sep 2005 21:22:30 +0200, Chris Sauls <ibisbasenji@gmail.com> wrote:

> I think you've got the right idea, except I might debate the merits of using 'typedef' over 'alias' in this case, and I'd probably use 'ptrdiff_t' rather than 'size_t'.

Well, I said size_t just because is more familiar. Anyway it's guaranteed that they are
the same size, isn't it? And the size is what matters...

About 'typedef' or 'alias', errr well, the whole point of typedef is to get type-safeness,
so the following get a compiler error:

typedef size_t HWND;
int n;
ShowWindow(n, SW_SHOW) // error cannot convert int to HANDLE.

Curiously enough, using a constant compiles fine:

ShowWindow(1729, SW_SHOW) // OK (?)

That's great for the 0, and not so great for other numbers.

But the true advantage of typedef over alias comes when you have 20 different types of handles,
all of them with a lot of functions incompatibles between them (HWND, HANDLE, HGLOBAL, HINSTANCE, HGDIOBJ, HKEY...)
It's too easy to get messed up, and call DestroyObject with a HANDLE, for example. typedef would
mark this as an error.

On Thu, 01 Sep 2005 23:26:16 +0200, pinzo@gmail.com wrote:

> On Thu, 01 Sep 2005 22:37:56 +0200, Ben Hinkle <bhinkle@mathworks.com> wrote:
> 
>> Storing pointers to non-GC data is fine (ie malloc'ed data or HANDLES).
>> What
>> you don't want to do is store an arbitrary value into a pointer type
>> since
>> it might accidentally point to some GC region.
> 
> The problem here is that HANDLE values, in general, are not pointers! They
> are arbitrary values
> cast to (void*) (well, maybe pointers from kernel space or from CSRSS
> space, etc.)
> So they could point just anywhere, including GC-data.

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.

In many Windows API and Macintosh contexts, a handle is a pointer to a pointer. The idea being that applications use the handle to deference the target data and that the operating system is free to move the target data about. However, in any Unix contexts, a handle is an array index. In both cases though, a handle is an indirect reference to data.

-- 
Derek Parnell
Melbourne, Australia
2/09/2005 8:08:27 AM

In article <op.swf0h2q40r3bey@pinzopc2>, pinzo@gmail.com says...
>
>On Thu, 01 Sep 2005 22:37:56 +0200, Ben Hinkle <bhinkle@mathworks.com>  =
>
>wrote:
>
>> Storing pointers to non-GC data is fine (ie malloc'ed data or HANDLES)=
>.  =
>
>> What
>> you don't want to do is store an arbitrary value into a pointer type  =
>
>> since
>> it might accidentally point to some GC region.
>
>The problem here is that HANDLE values, in general, are not pointers! Th= ey  =
>
>are arbitrary values
>cast to (void*) (well, maybe pointers from kernel space or from CSRSS  =
>
>space, etc.)
>So they could point just anywhere, including GC-data.

The definition of a "handle" is a pointer to a pointer.

-Sha

"Shammah Chancellor" <Shammah_member@pathlink.com> wrote in message news:df878o$251n$1@digitaldaemon.com...
> In article <op.swf0h2q40r3bey@pinzopc2>, pinzo@gmail.com says...
>>
>>On Thu, 01 Sep 2005 22:37:56 +0200, Ben Hinkle <bhinkle@mathworks.com>  =
>>
>>wrote:
>>
>>> Storing pointers to non-GC data is fine (ie malloc'ed data or HANDLES)=
>>.  =
>>
>>> What
>>> you don't want to do is store an arbitrary value into a pointer type  =
>>
>>> since
>>> it might accidentally point to some GC region.
>>
>>The problem here is that HANDLE values, in general, are not pointers! Th= ey  =
>>
>>are arbitrary values
>>cast to (void*) (well, maybe pointers from kernel space or from CSRSS  =
>>
>>space, etc.)
>>So they could point just anywhere, including GC-data.
>
> The definition of a "handle" is a pointer to a pointer.

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".

> -Sha
>
> 

On Thu, 1 Sep 2005 20:56:51 -0400, Ben Hinkle wrote:

[snip]

> 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.

<trivia>
Windows API assumes that no valid pointer will ever point anywhere in the
range of addresses 0x00000000 to 0x0000001F, and 0xFFFFFFFD to 0xFFFFFFFF.
And thus it allows Handles to contain integer values in the range -3 to 31
inclusive. These are usually reserved values for various things, such as
system defined Brushes, Fonts, etc... and error codes.
</trivia>

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
2/09/2005 11:35:49 AM

On Thu, 1 Sep 2005 20:56:51 -0400, Ben Hinkle wrote:

>> The definition of a "handle" is a pointer to a pointer.

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

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
2/09/2005 11:43:36 AM