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

[Eliot Miranda]

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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160509/fd971dec/attachment.htm