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

[Tobias Pape]

Hi,

On 09.05.2016, at 19:09, Eliot Miranda <eliot.miranda at gmail.com> wrote:

> 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

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