Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#21 LibGG uses void*

open
nobody
None
5
2012-04-16
2012-04-16
Jon Taylor
No

gg.h is rife with void*. This makes the whole library system not 64-bit clean as well as not portable across compilers....

Discussion

  • Peter Rosin
    Peter Rosin
    2012-04-16

    • status: open --> pending
     
  • Peter Rosin
    Peter Rosin
    2012-04-16

    Hi!

    Please explain how the mere presence of void pointers in an interface is a problem. It has got to be something that is done with those pointers. So, what is the problem exactly?

    Cheers,
    Peter

     
  • Jon Taylor
    Jon Taylor
    2012-04-16

    It will break the ("requires at most a recompile") guarantee that GGI has always had. It also removes the ability to hit the hardware directly in some cases and the ability to use/link arbitrary external binary blobs, both of which are very necessary for GGI to support. It also torpedoes optimization in the compiler by removing the ability to make references local rather than global in scope....

     
  • Jon Taylor
    Jon Taylor
    2012-04-16

    • status: pending --> open
     
  • Peter Rosin
    Peter Rosin
    2012-04-16

    You need to provide more detail, because I can't see why it's not OK for GGI to use void pointers when malloc/free does so. Searching the 'net for portability problems with void pointers just gives me stuff about code that assumes int and void pointers are the same size, which does not seem to be your concern. So, please provide more detail, possibly a link somewhere, and point to a specific API that exhibits the problem. Sweeping statements doesn't help. Thanks.

     
  • Jon Taylor
    Jon Taylor
    2012-04-17

    sizeof(int) != sizeof(void*) in many cases. That is what I assume you mean. It is unreasonable to expect legacy code to be rewritten for 64-bit compatibility when a primary selling point of GGI is its ability to encapsulate legacy interfaces....

     
  • Peter Rosin
    Peter Rosin
    2012-04-17

    Of course sizeof(int) isn't the same as sizeof(void*) for many ABIs. So what?

    What I mean is that *you* need to point out where GGI makes assumptions such as sizeof(int) == sizeof(void*), because I don't know of any such assumptions.

    If you mean that GGI compiled for one ABI should be usable by applications compiled for some other ABI, then of *course* you need to compile GGI *and* the application using the *same* ABI. But that seems so insane that I can't believe this is what you are suggesting that GGI should handle? Is it?

    I still don't know why you think void pointers are not portable. The size of *any* pointer is part of the ABI, but so are the size of ints, the calling convention and what not. What should GGI use if void pointers are (seemingly randomly) verboten? So, again, what is so special about void pointers?