Confused about IntPtr conversion problem.

  • Thread starter Thread starter Ken Varn
  • Start date Start date
K

Ken Varn

I have a managed C++ function that accepts an IntPtr argument. I am passing
in a variable of type HANDLE for the IntPtr argument. The compiler does not
issue any warnings for this, so I am assuming it is ok (maybe this is a bad
assumption). Anyhow, for some reason, the IntPtr is not set to the same
value that was passed in by HANDLE. It seems as though the type conversion
is not being done correctly. Here is the example:

void MyFunc(IntPtr Val)
{
IntPtr MyVal = Val;
}

void CallMyFunc()
{
HANDLE Test = NULL;

MyFunc(Test);
}

When this code is run, the value of MyVal appears to be getting set to the
pointer to Test rather than its value (NULL). Is this supposed to work this
way? Since HANDLE's typedef is void *, I am not sure why this is happening.

--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.

EmailID = varnk
Domain = Diebold.com
-----------------------------------
 
Hi Ken,
I have a managed C++ function that accepts an IntPtr argument. I am passing
in a variable of type HANDLE for the IntPtr argument. The compiler does not
issue any warnings for this, so I am assuming it is ok (maybe this is a bad
assumption).
Click to expand...

It should be OK. There's one IntPtr constructor that takes a void* as an
argument, so an implicit conversion should be possible.
Anyhow, for some reason, the IntPtr is not set to the same
value that was passed in by HANDLE. It seems as though the type conversion
is not being done correctly. Here is the example:

void MyFunc(IntPtr Val)
{
IntPtr MyVal = Val;
}

void CallMyFunc()
{
HANDLE Test = NULL;

MyFunc(Test);
}

When this code is run, the value of MyVal appears to be getting set to the
pointer to Test rather than its value (NULL). Is this supposed to work this
way? Since HANDLE's typedef is void *, I am not sure why this is
Click to expand...
happening.

HUmm... this does not happen to me here, I correctly get NULL passed in,
even with full optimizations enabled.... can you see what code is getting
generated by using ildasm?
 
I think I figured out what is happening. I may have misinterpreted the
VS.NET debugger output. I type-casted the HANDLE value as a (int *) to see
if I could get the pointer value, but I think the debugger actually shows
the pointer contents value which happens to be 0 in my application. So the
example that I provided is not quite accurate.

I can't figure out how to get the debugger to actually show the value of the
pointer itself. I have tried casting it as (int *), &(int *), (long), but
no luck. How do I get the debugger to actually show the pointer value? It
just shows {void}, which I assumed to be NULL. Bad assumption.

--
-----------------------------------
Ken Varn
Senior Software Engineer
Diebold Inc.

EmailID = varnk
Domain = Diebold.com
-----------------------------------
 
As you satte in a later message, it is almost certainly a debugger issue.
Which version of VC/VS is this? It is definitely a well known issue with
7.0/2002 that there is no way to show the value of a native pointer (or
IntPtr) when you are working with code compiled /clr and might still happen
in a few cases with 7.1/2003.

Ronald Laeremans
Visual C++ team
 
Back
Top