clarification on void pointer

[Satya]

Hi all,

i have got some source files and a header file from third party along with a dll file and a lib file. In that i have a function prototype like

  HANDLE func1(int a);

and if i search for HANDLE it goes to one of
the windows file and it is typedef as

typedef void *HANDLE;

from this i understand that HANDLE is a pointer pointing to void, now here is the problem how should i conclude to which type it actually points to that is a float or int or how?? could somebody help to explain this. In which cases is void * really useful.

thanks and regards,
satya

[memcpy]

A void * pointer is treated as a "wild-card", as it can point to anything. Almost always, it is typecasted before use.

However, you can't do pointer arithmetic directly on a void pointer, as the compiler doesn't know the correct "size" to modify the pointer by.

For the handle, I'm not sure (about Windows-specific stuff). It could be pointing to anything -- from a simple int to a huge struct.

[ledow]

You would need to read the documentation of the DLL file that will specify what that function returns. All "void *" or "HANDLE" mean is that it's given you a pointer to memory. What's *IN* that memory is up to the function that put it there, and could be absolutely anything and you shouldn't "guess" at what it is. The function documentation will tell you. If it doesn't, shout at the DLL author.

[dmh2000]

in this case void * is used so whatever it points to is meant to be opaque. that is the Windows API doesn't want to specify what it points to, you just use it as the API requires. that technique is used a lot in C libraries, where internally it uses some data structure but doesn't want to specify exactly what it is. that helps the application program because it won't be coupled to the internal definition of the data structure and it lets the library change without affecting the application.

another use of void * is to have an API that lets one function pass any data structure to another function without having it spelled out. this can be used to let the caller pass in some user data structure that the called function saves but doesn't look at. for example, in Window _beginthread lets you pass a void * to the new thread, but the _beginthread API doesn't need to know what it is. the caller and the new thread need to agree on what it really is, but the intermediate _beginthread API doesnt.

[iMalc]

You never need to dereference it, in fact it quite possibly is not even actually a pointer. It may be just a magic number that the OS typecasted to a void*.

[Satya]

Hi all,

Thank you very much for your replies. Actually the function func1 i mentioned is something like this

handle = HANDLE portopen(unsigned char port);

so i think the portopen function would return a pointer to the port. In the program all the further statements to access the port state is all done using the HANDLE returned from the portopen like

  PortGetState(handle,&state);

so can i conclude that the type of value to which the HANDLE is pointing is not that much important??

thanks and regards,
satya

[ledow]

The type isn't important to YOU. Unless you want to play with the actual details, or unless the DLL's API requires you to do things with it (misusing any bit of code that was written with certain conditions on its use is just asking for trouble). But if you assume it's of any particular type without the DLL guaranteeing that, you're going to end up hurting yourself.

And, more likely, it would be a pointer to some internal structure that the DLL uses to keep track of ports and their state, rather than just a direct pointer to the port (which would be pretty useless on its own). That structure might hold information like the remote connection, the time it was opened, the size and location of the buffer it's created to handle the data for it, and a million and one other things. The format of that structure would be specified in the DLL API if you're required to use it or do anything special.

Basically, never assume that the returned handle from a "closed box" is ANYTHING at all. Don't dereference it, don't try to get smart with it, don't "misuse" it even if you know exactly what it is. Because the point of something like that is that the DLL has certain conditions that it expects YOU to fulfill and if you don't, your program won't work (either now or in the next upgrade of the DLL, for instance, when the DLL author decides to change the entire structure it returns but you WOULDN'T need to know if you were following his API conditions properly, because all his functions would handle the new format and you shouldn't have been playing with the pointer unless he said so).

But, most importantly, DON'T use people's code without checking their assumptions. That DLL is not necessarily built assuming you would deference or change that pointer in any way. Hell, I've seen DLL's where the handle is only valid until the next function call from that same DLL, etc. and if you don't KNOW that, you'll spend ages wondering why your program isn't working. If you break the DLL API assumptions/conditions, then you will break your code - no different to using another programmer's source code and not bothering to read the function preconditions, etc. "Junk in, junk out" is the motto for most "closed box" programming like a DLL, and if you don't follow their rules (even down to things like running DLL initialisation routines properly and before anything else, etc.) you are just preparing yourself for failure.

A void pointer is a black box. It's just a place in memory that could represent anything from a full-blown structure with 1000 elements, to a character array, to an int, a float, a double, hell, maybe even just a direct hardware port. Without knowing the DLL API, you have no idea and you will cause yourself trouble to guessing.

Always treat it as an "unknown" that just works if you don't play with it, and always read the documentation for code you intend to use. Don't just assume you can call any function in any DLL at any time and have it work everywhere. Hell, I know that with SDL (a huge graphics / input library that lots of games use) you *can* do things like specify a window icon before you create a window on Windows with SDL 1.2 - but it only works on some versions of SDL, on some platforms and not consistently - try it on Linux and things actually crash before you create a window. But if you read the documentation, it tells you exactly WHEN it will work and when it won't.

[iMalc]

so can i conclude that the type of value to which the HANDLE is pointing is not that much important??

Correct.