Smalltalk › Squeak › Squeak VM

[commit][3704] converting int to pointer is 64bits risky, better use long even for dummy

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

commits-3

[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;

Eliot Miranda-2

Re: [commit][3704] converting int to pointer is 64bits risky, better use long even for dummy

> On May 6, 2016, at 1:37 PM, [hidden email] 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;
>

Tobias Pape

Re: [commit][3704] converting int to pointer is 64bits risky, better use long even for dummy

On 07.05.2016, at 00:20, Eliot Miranda <[hidden email]> wrote:

>
>
>
>> On May 6, 2016, at 1:37 PM, [hidden email] 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

Eliot Miranda-2

Re: [commit][3704] converting int to pointer is 64bits risky, better use long even for dummy

> On May 6, 2016, at 10:41 PM, Tobias Pape <[hidden email]> wrote:
>
>
>
>> On 07.05.2016, at 00:20, Eliot Miranda <[hidden email]> wrote:
>>
>>
>>
>>
>>> On May 6, 2016, at 1:37 PM, [hidden email] 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

Ryan Macnak

Re: [commit][3704] converting int to pointer is 64bits risky, better use long even for dummy

On Sat, May 7, 2016 at 7:49 AM, Eliot Miranda <[hidden email]> wrote:

> On May 6, 2016, at 10:41 PM, Tobias Pape <[hidden email]> wrote:
>
>
>
>> On 07.05.2016, at 00:20, Eliot Miranda <[hidden email]> wrote:
>>
>>
>>
>>
>>> On May 6, 2016, at 1:37 PM, [hidden email] 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

Eliot Miranda-2

Re: [commit][3704] converting int to pointer is 64bits risky, better use long even for dummy

Hi Ryan, Tobias, All,

On May 8, 2016, at 10:28 AM, Ryan Macnak <[hidden email]> wrote:

On Sat, May 7, 2016 at 7:49 AM, Eliot Miranda <[hidden email]> wrote:

> On May 6, 2016, at 10:41 PM, Tobias Pape <[hidden email]> wrote:
>
>
>
>> On 07.05.2016, at 00:20, Eliot Miranda <[hidden email]> wrote:
>>
>>
>>
>>
>>> On May 6, 2016, at 1:37 PM, [hidden email] 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

David T. Lewis

Re: [commit][3704] converting int to pointer is 64bits risky, better use long even for dummy

+1000 for your option 1, couldn't agree more :-)

Date

> Hi Ryan, Tobias, All,
>
>> On May 8, 2016, at 10:28 AM, Ryan Macnak <[hidden email]> wrote:
>>
>>
>>
>>> On Sat, May 7, 2016 at 7:49 AM, Eliot Miranda <[hidden email]>
>>> wrote:
>>>
>>>
>>> > On May 6, 2016, at 10:41 PM, Tobias Pape <[hidden email]> wrote:
>>> >
>>> >
>>> >
>>> >> On 07.05.2016, at 00:20, Eliot Miranda <[hidden email]>
>>> wrote:
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>> On May 6, 2016, at 1:37 PM, [hidden email] 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
>>
>

Tobias Pape

Re: [commit][3704] converting int to pointer is 64bits risky, better use long even for dummy

In reply to this post by Eliot Miranda-2

Hi,

On 09.05.2016, at 19:09, Eliot Miranda <[hidden email]> wrote:

> Hi Ryan, Tobias, All,
>
> On May 8, 2016, at 10:28 AM, Ryan Macnak <[hidden email]> wrote:
>
>>
>>
>> On Sat, May 7, 2016 at 7:49 AM, Eliot Miranda <[hidden email]> wrote:
>>
>>
>> > On May 6, 2016, at 10:41 PM, Tobias Pape <[hidden email]> wrote:
>> >
>> >
>> >
>> >> On 07.05.2016, at 00:20, Eliot Miranda <[hidden email]> wrote:
>> >>
>> >>
>> >>
>> >>
>> >>> On May 6, 2016, at 1:37 PM, [hidden email] 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

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

Nicolas Cellier

Re: [commit][3704] converting int to pointer is 64bits risky, better use long even for dummy

In reply to this post by Eliot Miranda-2

2016-05-09 19:09 GMT+02:00 Eliot Miranda <[hidden email]>:

Hi Ryan, Tobias, All,

On May 8, 2016, at 10:28 AM, Ryan Macnak <[hidden email]> wrote:

On Sat, May 7, 2016 at 7:49 AM, Eliot Miranda <[hidden email]> wrote:

> On May 6, 2016, at 10:41 PM, Tobias Pape <[hidden email]> wrote:
>
>
>
>> On 07.05.2016, at 00:20, Eliot Miranda <[hidden email]> wrote:
>>
>>
>>
>>
>>> On May 6, 2016, at 1:37 PM, [hidden email] 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

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...)

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?

+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

build_win32_recent_cygwin_X86_64.patch (9K) Download Attachment