Like Tree2Likes
  • 1 Post By iMalc
  • 1 Post By Satya

clarification on void pointer

This is a discussion on clarification on void pointer within the C Programming forums, part of the General Programming Boards category; Hi all, i have got some source files and a header file from third party along with a dll file ...

  1. #1
    Registered User
    Join Date
    Feb 2012
    Posts
    93

    clarification on void pointer

    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
    Code:
      HANDLE func1(int a);
    and if i search for HANDLE it goes to one of
    the windows file and it is typedef as

    Code:
    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

  2. #2
    Registered User
    Join Date
    Dec 2011
    Posts
    795
    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.

  3. #3
    Registered User ledow's Avatar
    Join Date
    Dec 2011
    Posts
    435
    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.

    - Compiler warnings are like "Bridge Out Ahead" warnings. DON'T just ignore them.
    - A compiler error is something SO stupid that the compiler genuinely can't carry on with its job. A compiler warning is the compiler saying "Well, that's bloody stupid but if you WANT to ignore me..." and carrying on.
    - The best debugging tool in the world is a bunch of printf()'s for everything important around the bits you think might be wrong.

  4. #4
    Registered User
    Join Date
    Mar 2011
    Posts
    546
    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.

  5. #5
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,308
    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*.
    Salem likes this.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  6. #6
    Registered User
    Join Date
    Feb 2012
    Posts
    93
    Hi all,

    Thank you very much for your replies. Actually the function func1 i mentioned is something like this
    Code:
    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
    Code:
      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
    iMalc likes this.

  7. #7
    Registered User ledow's Avatar
    Join Date
    Dec 2011
    Posts
    435
    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.

    - Compiler warnings are like "Bridge Out Ahead" warnings. DON'T just ignore them.
    - A compiler error is something SO stupid that the compiler genuinely can't carry on with its job. A compiler warning is the compiler saying "Well, that's bloody stupid but if you WANT to ignore me..." and carrying on.
    - The best debugging tool in the world is a bunch of printf()'s for everything important around the bits you think might be wrong.

  8. #8
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,308
    Quote Originally Posted by Satya View Post
    so can i conclude that the type of value to which the HANDLE is pointing is not that much important??
    Correct.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Pointer to a Pointer clarification
    By Tommo in forum C Programming
    Replies: 13
    Last Post: 08-30-2007, 10:14 AM
  2. Replies: 4
    Last Post: 08-27-2007, 11:51 PM
  3. pointer clarification
    By DMaxJ in forum C Programming
    Replies: 1
    Last Post: 06-04-2003, 09:14 AM
  4. Pointer clarification
    By Spectrum48k in forum C++ Programming
    Replies: 4
    Last Post: 02-23-2003, 06:22 PM
  5. character pointer clarification
    By theweirdo in forum C Programming
    Replies: 3
    Last Post: 01-29-2002, 09:51 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21