[commit][3704] converting int to pointer is 64bits risky, better use long even for dummy
Revision: 3704 Author: nice Date: 2016-05-06 13:37:49 -0700 (Fri, 06 May 2016) Log Message: ----------- converting int to pointer is 64bits risky, better use long even for dummy
Modified Paths: -------------- branches/Cog/platforms/iOS/plugins/SqueakFFIPrims/dummyFFI.c branches/Cog/platforms/iOS/vm/iPhone/plugins/SqueakFFIPrims/dummyFFI.c
Modified: branches/Cog/platforms/iOS/plugins/SqueakFFIPrims/dummyFFI.c =================================================================== --- branches/Cog/platforms/iOS/plugins/SqueakFFIPrims/dummyFFI.c 2016-05-06 20:22:49 UTC (rev 3703) +++ branches/Cog/platforms/iOS/plugins/SqueakFFIPrims/dummyFFI.c 2016-05-06 20:37:49 UTC (rev 3704) @@ -157,7 +157,7 @@
/* ffiFree: Free space from the external heap */ -int ffiFree(int pointer) +int ffiFree(long pointer) { return 1; }
Modified: branches/Cog/platforms/iOS/vm/iPhone/plugins/SqueakFFIPrims/dummyFFI.c =================================================================== --- branches/Cog/platforms/iOS/vm/iPhone/plugins/SqueakFFIPrims/dummyFFI.c 2016-05-06 20:22:49 UTC (rev 3703) +++ branches/Cog/platforms/iOS/vm/iPhone/plugins/SqueakFFIPrims/dummyFFI.c 2016-05-06 20:37:49 UTC (rev 3704) @@ -157,7 +157,7 @@ }
-int ffiFree(int ptr) +int ffiFree(long ptr) { if (ptr) free((void *)ptr); return 1;
On May 6, 2016, at 1:37 PM, commits@squeakvm.org wrote:
Revision: 3704 Author: nice Date: 2016-05-06 13:37:49 -0700 (Fri, 06 May 2016) Log Message:
converting int to pointer is 64bits risky, better use long even for dummy
It isn't risky, it's broken :-)
Modified Paths:
branches/Cog/platforms/iOS/plugins/SqueakFFIPrims/dummyFFI.c branches/Cog/platforms/iOS/vm/iPhone/plugins/SqueakFFIPrims/dummyFFI.c
Modified: branches/Cog/platforms/iOS/plugins/SqueakFFIPrims/dummyFFI.c
--- branches/Cog/platforms/iOS/plugins/SqueakFFIPrims/dummyFFI.c 2016-05-06 20:22:49 UTC (rev 3703) +++ branches/Cog/platforms/iOS/plugins/SqueakFFIPrims/dummyFFI.c 2016-05-06 20:37:49 UTC (rev 3704) @@ -157,7 +157,7 @@
/* ffiFree: Free space from the external heap */ -int ffiFree(int pointer) +int ffiFree(long pointer) { return 1; }
Modified: branches/Cog/platforms/iOS/vm/iPhone/plugins/SqueakFFIPrims/dummyFFI.c
--- branches/Cog/platforms/iOS/vm/iPhone/plugins/SqueakFFIPrims/dummyFFI.c 2016-05-06 20:22:49 UTC (rev 3703) +++ branches/Cog/platforms/iOS/vm/iPhone/plugins/SqueakFFIPrims/dummyFFI.c 2016-05-06 20:37:49 UTC (rev 3704) @@ -157,7 +157,7 @@ }
-int ffiFree(int ptr) +int ffiFree(long ptr) { if (ptr) free((void *)ptr); return 1;
On 07.05.2016, at 00:20, Eliot Miranda eliot.miranda@gmail.com wrote:
On May 6, 2016, at 1:37 PM, commits@squeakvm.org wrote:
Revision: 3704 Author: nice Date: 2016-05-06 13:37:49 -0700 (Fri, 06 May 2016) Log Message:
converting int to pointer is 64bits risky, better use long even for dummy
It isn't risky, it's broken :-)
What about intptr_t then?
Best regards -tobias
On May 6, 2016, at 10:41 PM, Tobias Pape Das.Linux@gmx.de wrote:
On 07.05.2016, at 00:20, Eliot Miranda eliot.miranda@gmail.com wrote:
On May 6, 2016, at 1:37 PM, commits@squeakvm.org wrote:
Revision: 3704 Author: nice Date: 2016-05-06 13:37:49 -0700 (Fri, 06 May 2016) Log Message:
converting int to pointer is 64bits risky, better use long even for dummy
It isn't risky, it's broken :-)
What about intptr_t then?
Rejected because it's a pretentious neologism, and because it's not a basic type. long however, is a basic type, is big enough to hold a pointer, is not pretentious, and is, in fact what intptr_t is defined in terms of anyway.
If we have to add support for all the possible renaming a if the basic integer types in the type inference machinery we'll have numbers in the double digits. KISS.
Best regards -tobias
On Sat, May 7, 2016 at 7:49 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
On May 6, 2016, at 10:41 PM, Tobias Pape Das.Linux@gmx.de wrote:
On 07.05.2016, at 00:20, Eliot Miranda eliot.miranda@gmail.com wrote:
On May 6, 2016, at 1:37 PM, commits@squeakvm.org wrote:
Revision: 3704 Author: nice Date: 2016-05-06 13:37:49 -0700 (Fri, 06 May 2016) Log Message:
converting int to pointer is 64bits risky, better use long even for
dummy
It isn't risky, it's broken :-)
What about intptr_t then?
Rejected because it's a pretentious neologism, and because it's not a basic type. long however, is a basic type, is big enough to hold a pointer, is not pretentious, and is, in fact what intptr_t is defined in terms of anyway.
Not on all platforms, which is why intptr_t exists. long is only required to be at least 32 bits, not to be wide enough to hold a pointer. Windows is an LLP64 system.
If we have to add support for all the possible renaming a if the basic integer types in the type inference machinery we'll have numbers in the double digits. KISS.
Best regards -tobias
Hi Ryan, Tobias, All,
On May 8, 2016, at 10:28 AM, Ryan Macnak rmacnak@gmail.com wrote:
On Sat, May 7, 2016 at 7:49 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
On May 6, 2016, at 10:41 PM, Tobias Pape Das.Linux@gmx.de wrote:
On 07.05.2016, at 00:20, Eliot Miranda eliot.miranda@gmail.com wrote:
On May 6, 2016, at 1:37 PM, commits@squeakvm.org wrote:
Revision: 3704 Author: nice Date: 2016-05-06 13:37:49 -0700 (Fri, 06 May 2016) Log Message:
converting int to pointer is 64bits risky, better use long even for dummy
It isn't risky, it's broken :-)
What about intptr_t then?
Rejected because it's a pretentious neologism, and because it's not a basic type. long however, is a basic type, is big enough to hold a pointer, is not pretentious, and is, in fact what intptr_t is defined in terms of anyway.
Not on all platforms, which is why intptr_t exists. long is only required to be at least 32 bits, not to be wide enough to hold a pointer. Windows is an LLP64 system.
Ugh. Well that holes my argument below the water line. No point going into outrage over what an awful decision Microsoft took, and ignorant of me (but sizeof(long) is now a real problem in Slang :-( ). But it seems to me we still have choices:
1. declare all platform function arguments that take pointers as taking void * 2. declare all platform function arguments that take pointers as taking intptr_t 3. declare all platform function arguments that take pointers as taking sqInt
My preference is 1. I really dislike the proliferation of specialized integer types such as intptr_t and size_t. They're neologisms and as such may not be supported in some platforms (I'm still using gcc 3.4 on win32 cuz the last time I tried to update Cygwin to something that supported both 32- & 64- bits it broke 32-bit compilation in the mingw32 platform includes). Further, they complicate the type inferrence machinery
3. doesn't work for the "legacy" 64-bit VM, which supports mixed mode compilation, 64-bit oops on 32-bits (sqInt bigger than needed to represent a pointer) and 32-bit oops on 64-bits (sqInt smaller than needed to represent a pointer).
1. calls a spade a spade. I prefer 1. Yes, both sides have to cast to get integral values but it declares the intent, to pass a pointer, better than intptr_t IMO.
Thoughts, other ideas?
If we have to add support for all the possible renaming a if the basic integer types in the type inference machinery we'll have numbers in the double digits. KISS.
Best regards -tobias
+1000 for your option 1, couldn't agree more :-)
Date
Hi Ryan, Tobias, All,
On May 8, 2016, at 10:28 AM, Ryan Macnak rmacnak@gmail.com wrote:
On Sat, May 7, 2016 at 7:49 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
On May 6, 2016, at 10:41 PM, Tobias Pape Das.Linux@gmx.de wrote:
On 07.05.2016, at 00:20, Eliot Miranda eliot.miranda@gmail.com
wrote:
On May 6, 2016, at 1:37 PM, commits@squeakvm.org wrote:
Revision: 3704 Author: nice Date: 2016-05-06 13:37:49 -0700 (Fri, 06 May 2016) Log Message:
converting int to pointer is 64bits risky, better use long even for
dummy
It isn't risky, it's broken :-)
What about intptr_t then?
Rejected because it's a pretentious neologism, and because it's not a basic type. long however, is a basic type, is big enough to hold a pointer, is not pretentious, and is, in fact what intptr_t is defined in terms of anyway.
Not on all platforms, which is why intptr_t exists. long is only required to be at least 32 bits, not to be wide enough to hold a pointer. Windows is an LLP64 system.
Ugh. Well that holes my argument below the water line. No point going into outrage over what an awful decision Microsoft took, and ignorant of me (but sizeof(long) is now a real problem in Slang :-( ). But it seems to me we still have choices:
- declare all platform function arguments that take pointers as taking
void * 2. declare all platform function arguments that take pointers as taking intptr_t 3. declare all platform function arguments that take pointers as taking sqInt
My preference is 1. I really dislike the proliferation of specialized integer types such as intptr_t and size_t. They're neologisms and as such may not be supported in some platforms (I'm still using gcc 3.4 on win32 cuz the last time I tried to update Cygwin to something that supported both 32- & 64- bits it broke 32-bit compilation in the mingw32 platform includes). Further, they complicate the type inferrence machinery
- doesn't work for the "legacy" 64-bit VM, which supports mixed mode
compilation, 64-bit oops on 32-bits (sqInt bigger than needed to represent a pointer) and 32-bit oops on 64-bits (sqInt smaller than needed to represent a pointer).
- calls a spade a spade. I prefer 1. Yes, both sides have to cast to
get integral values but it declares the intent, to pass a pointer, better than intptr_t IMO.
Thoughts, other ideas?
If we have to add support for all the possible renaming a if the basic integer types in the type inference machinery we'll have numbers in the double digits. KISS.
Best regards -tobias
Hi,
On 09.05.2016, at 19:09, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Ryan, Tobias, All,
On May 8, 2016, at 10:28 AM, Ryan Macnak rmacnak@gmail.com wrote:
On Sat, May 7, 2016 at 7:49 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
On May 6, 2016, at 10:41 PM, Tobias Pape Das.Linux@gmx.de wrote:
On 07.05.2016, at 00:20, Eliot Miranda eliot.miranda@gmail.com wrote:
On May 6, 2016, at 1:37 PM, commits@squeakvm.org wrote:
Revision: 3704 Author: nice Date: 2016-05-06 13:37:49 -0700 (Fri, 06 May 2016) Log Message:
converting int to pointer is 64bits risky, better use long even for dummy
It isn't risky, it's broken :-)
What about intptr_t then?
Rejected because it's a pretentious neologism, and because it's not a basic type. long however, is a basic type, is big enough to hold a pointer, is not pretentious, and is, in fact what intptr_t is defined in terms of anyway.
Not on all platforms, which is why intptr_t exists. long is only required to be at least 32 bits, not to be wide enough to hold a pointer. Windows is an LLP64 system.
Ugh. Well that holes my argument below the water line. No point going into outrage over what an awful decision Microsoft took, and ignorant of me (but sizeof(long) is now a real problem in Slang :-( ). But it seems to me we still have choices:
- declare all platform function arguments that take pointers as taking void *
- declare all platform function arguments that take pointers as taking intptr_t
- declare all platform function arguments that take pointers as taking sqInt
My preference is 1. I really dislike the proliferation of specialized integer types such as intptr_t and size_t. They're neologisms
Welllll C99 is 17 Years old now, nearly an adult, and C11 also beyond toddler already.
and as such may not be supported in some platforms (I'm still using gcc 3.4 on win32
The first release of gcc 3.4 was in April 2004, the last gcc 3.4 was released in March 2006. And GCC supports inptr_t since long before GCC 3.3. It is interesting, because _even_ MSVC supports intptr_t since 2003.
Also, Cygwin recommends intptr_t. https://www.cygwin.com/faq.html#faq.programming.64bitporting
"Along the same lines don't use the type int in pointer arithmetic. Don't cast pointers to int, don't cast pointer differences to int, and don't store pointer differences in an int type. Use the types intptr_t, uintptr_t andptrdiff_t instead, they are designed for performing architecture-independent pointer arithmetic."
That being said, NOT casting pointers to int-likes sounds like a very good idea.
Best -Tobias
cuz the last time I tried to update Cygwin to something that supported both 32- & 64- bits it broke 32-bit compilation in the mingw32 platform includes). Further, they complicate the type inferrence machinery
doesn't work for the "legacy" 64-bit VM, which supports mixed mode compilation, 64-bit oops on 32-bits (sqInt bigger than needed to represent a pointer) and 32-bit oops on 64-bits (sqInt smaller than needed to represent a pointer).
calls a spade a spade. I prefer 1. Yes, both sides have to cast to get integral values but it declares the intent, to pass a pointer, better than intptr_t IMO.
Thoughts, other ideas?
If we have to add support for all the possible renaming a if the basic integer types in the type inference machinery we'll have numbers in the double digits. KISS.
Best regards -tobias
2016-05-09 19:09 GMT+02:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Ryan, Tobias, All,
On May 8, 2016, at 10:28 AM, Ryan Macnak rmacnak@gmail.com wrote:
On Sat, May 7, 2016 at 7:49 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
On May 6, 2016, at 10:41 PM, Tobias Pape Das.Linux@gmx.de wrote:
On 07.05.2016, at 00:20, Eliot Miranda eliot.miranda@gmail.com
wrote:
On May 6, 2016, at 1:37 PM, commits@squeakvm.org wrote:
Revision: 3704 Author: nice Date: 2016-05-06 13:37:49 -0700 (Fri, 06 May 2016) Log Message:
converting int to pointer is 64bits risky, better use long even for
dummy
It isn't risky, it's broken :-)
What about intptr_t then?
Rejected because it's a pretentious neologism, and because it's not a basic type. long however, is a basic type, is big enough to hold a pointer, is not pretentious, and is, in fact what intptr_t is defined in terms of anyway.
Not on all platforms, which is why intptr_t exists. long is only required to be at least 32 bits, not to be wide enough to hold a pointer. Windows is an LLP64 system.
Ugh. Well that holes my argument below the water line. No point going into outrage over what an awful decision Microsoft took, and ignorant of me (but sizeof(long) is now a real problem in Slang :-( ). But it seems to me we still have choices:
- declare all platform function arguments that take pointers as taking
void * 2. declare all platform function arguments that take pointers as taking intptr_t 3. declare all platform function arguments that take pointers as taking sqInt
My preference is 1. I really dislike the proliferation of specialized integer types such as intptr_t and size_t. They're neologisms and as such may not be supported in some platforms (I'm still using gcc 3.4 on win32 cuz the last time I tried to update Cygwin to something that supported both 32- & 64- bits it broke 32-bit compilation in the mingw32 platform includes). Further, they complicate the type inferrence machinery
Hi Eliot, I managed to have a mingw32 built with a recent cygwin X86_64, just in case... See attached patch. I used clang because it does not suffer from ldexp bug (32 bits gcc does, 64 bits doesn't...). It would then be possible to build the X64 version, but some work is needed (like the win32 backtrace.c, a lot of int -> sqInt declarations neeeded, using etc...)
- doesn't work for the "legacy" 64-bit VM, which supports mixed mode
compilation, 64-bit oops on 32-bits (sqInt bigger than needed to represent a pointer) and 32-bit oops on 64-bits (sqInt smaller than needed to represent a pointer).
- calls a spade a spade. I prefer 1. Yes, both sides have to cast to
get integral values but it declares the intent, to pass a pointer, better than intptr_t IMO.
Thoughts, other ideas?
+1 for void *, or more relevant information.
Didn't Bert proposed a union a few years ago? Ah no, it was for oop maybe. Can't find the relevant thread, but it was interesting.
If we have to add support for all the possible renaming a if the basic integer types in the type inference machinery we'll have numbers in the double digits. KISS.
Best regards -tobias
vm-dev@lists.squeakfoundation.org
-
commits＠squeakvm.org -
David T. Lewis -
Eliot Miranda -
Nicolas Cellier -
Ryan Macnak -
Tobias Pape