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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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....
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
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....
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.
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....
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?