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

David T. Lewis lewis at mail.msen.com
Mon May 9 18:10:48 UTC 2016


+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 at gmail.com> wrote:
>>
>>
>>
>>> On Sat, May 7, 2016 at 7:49 AM, Eliot Miranda <eliot.miranda at gmail.com>
>>> wrote:
>>>
>>>
>>> > On May 6, 2016, at 10:41 PM, Tobias Pape <Das.Linux at gmx.de> wrote:
>>> >
>>> >
>>> >
>>> >> On 07.05.2016, at 00:20, Eliot Miranda <eliot.miranda at gmail.com>
>>> wrote:
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>> On May 6, 2016, at 1:37 PM, commits at 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
>>
>




More information about the Vm-dev mailing list