Jump to page: 1 2 3
Thread overview
64Bit compatibility warnings
Jan 20, 2012
Trass3r
Jan 20, 2012
bearophile
Jan 20, 2012
Peter Alexander
Jan 21, 2012
Stewart Gordon
Jan 21, 2012
Timon Gehr
Jan 21, 2012
Stewart Gordon
Jan 21, 2012
Matt Soucy
Jan 21, 2012
Matt Soucy
Jan 21, 2012
Trass3r
Jan 21, 2012
Nick Sabalausky
Jan 21, 2012
Trass3r
Jan 21, 2012
Vladimir Panteleev
Jan 21, 2012
Richard Webb
Jan 21, 2012
Jonathan M Davis
Jan 21, 2012
Marco Leise
Jan 21, 2012
Peter Alexander
Jan 21, 2012
Stewart Gordon
Jan 21, 2012
bearophile
Jan 24, 2012
Don Clugston
Jan 24, 2012
Stewart Gordon
Jan 24, 2012
Iain Buclaw
January 20, 2012
Could we please have at least a warning if code isn't compatible with 64Bit?
It's really annoying to test out some code and having to fix a bunch of stupid uint->size_t bugs just because the author is still on a 32 bit machine.

Is that feasible?
January 20, 2012
Trass3r:

> Could we please have at least a warning if code isn't compatible with
> 64Bit?
> It's really annoying to test out some code and having to fix a bunch of
> stupid uint->size_t bugs just because the author is still on a 32 bit
> machine.
> 
> Is that feasible?

Time ago I have suggested this, but it was refused: http://d.puremagic.com/issues/show_bug.cgi?id=5063

So in practice what are you suggesting to do?

Bye,
bearophile
January 20, 2012
On 20/01/12 12:25 AM, Trass3r wrote:
> Could we please have at least a warning if code isn't compatible with
> 64Bit?
> It's really annoying to test out some code and having to fix a bunch of
> stupid uint->size_t bugs just because the author is still on a 32 bit
> machine.
>
> Is that feasible?

In general, no. What you're asking is for the compiler to compile your code twice, once for 32-bit and once for 64-bit.

Remember that size_t is defined in druntime, not the language, so the compiler doesn't know what size_t is ahead of time.

version(D_LP64)
{
    alias ulong size_t;
    alias long  ptrdiff_t;
    alias long  sizediff_t;
}
else
{
    alias uint  size_t;
    alias int   ptrdiff_t;
    alias int   sizediff_t;
}
January 21, 2012
On 20/01/2012 00:46, Peter Alexander wrote:
> On 20/01/12 12:25 AM, Trass3r wrote:
>> Could we please have at least a warning if code isn't compatible with
>> 64Bit?
>> It's really annoying to test out some code and having to fix a bunch of
>> stupid uint->size_t bugs just because the author is still on a 32 bit
>> machine.
>>
>> Is that feasible?
>
> In general, no. What you're asking is for the compiler to compile your code twice, once
> for 32-bit and once for 64-bit.

No it isn't.  It's basically asking to make size_t/ptrdiff_t not implicitly convertible to uint/int, or at least issue a warning if you implicitly convert between them.

At least some Microsoft C++ complier versions have this warning.

Stewart.
January 21, 2012
On 01/21/2012 01:48 AM, Stewart Gordon wrote:
> On 20/01/2012 00:46, Peter Alexander wrote:
>> On 20/01/12 12:25 AM, Trass3r wrote:
>>> Could we please have at least a warning if code isn't compatible with
>>> 64Bit?
>>> It's really annoying to test out some code and having to fix a bunch of
>>> stupid uint->size_t bugs just because the author is still on a 32 bit
>>> machine.
>>>
>>> Is that feasible?
>>
>> In general, no. What you're asking is for the compiler to compile your
>> code twice, once
>> for 32-bit and once for 64-bit.
>
> No it isn't. It's basically asking to make size_t/ptrdiff_t not
> implicitly convertible to uint/int, or at least issue a warning if you
> implicitly convert between them.
>
> At least some Microsoft C++ complier versions have this warning.
>
> Stewart.

I generally like the idea of making size_t strongly typed, but
that would necessitate X!size_t to become a distinct instantiation from X!uint or X!ulong. Furthermore, it would break all existing D programs that are deliberately not 64 bit aware =).
January 21, 2012
On 21/01/2012 01:16, Timon Gehr wrote:
<snip>
> I generally like the idea of making size_t strongly typed, but
> that would necessitate X!size_t to become a distinct instantiation from X!uint or X!ulong.
> Furthermore, it would break all existing D programs that are deliberately not 64 bit aware
> =).

You mean compilers that target a 32-bit platform and rely on the runtime environment to ensure CTFE is consistent with runtime evaluation of the same function?

Stewart.
January 21, 2012
On 01/20/2012 08:21 PM, Stewart Gordon wrote:
> On 21/01/2012 01:16, Timon Gehr wrote:
> <snip>
>> I generally like the idea of making size_t strongly typed, but
>> that would necessitate X!size_t to become a distinct instantiation
>> from X!uint or X!ulong.
>> Furthermore, it would break all existing D programs that are
>> deliberately not 64 bit aware
>> =).
>
> You mean compilers that target a 32-bit platform and rely on the runtime
> environment to ensure CTFE is consistent with runtime evaluation of the
> same function?
>
> Stewart.

Couldn't it be handled by a special switch on 64 bit compilers, and disabled normally? That way, the default behavior doesn't change, but all one would have to do is say "
-Matt Soucy
January 21, 2012
On 01/20/2012 08:24 PM, Matt Soucy wrote:
> On 01/20/2012 08:21 PM, Stewart Gordon wrote:
>> On 21/01/2012 01:16, Timon Gehr wrote:
>> <snip>
>>> I generally like the idea of making size_t strongly typed, but
>>> that would necessitate X!size_t to become a distinct instantiation
>>> from X!uint or X!ulong.
>>> Furthermore, it would break all existing D programs that are
>>> deliberately not 64 bit aware
>>> =).
>>
>> You mean compilers that target a 32-bit platform and rely on the runtime
>> environment to ensure CTFE is consistent with runtime evaluation of the
>> same function?
>>
>> Stewart.
>
> Couldn't it be handled by a special switch on 64 bit compilers, and
> disabled normally? That way, the default behavior doesn't change, but
> all one would have to do is say "
> -Matt Soucy
...I totally meant "-alertx64compatability", but a "-MattSoucy" compiler flag would be amusing as well. And scary that I would warrant a compiler flag.
Either way, a flag like that would still require making size_t strongly typed...
-Matt Soucy
January 21, 2012
Am 21.01.2012, 02:16 Uhr, schrieb Timon Gehr <timon.gehr@gmx.ch>:

> On 01/21/2012 01:48 AM, Stewart Gordon wrote:
>> On 20/01/2012 00:46, Peter Alexander wrote:
>>> On 20/01/12 12:25 AM, Trass3r wrote:
>>>> Could we please have at least a warning if code isn't compatible with
>>>> 64Bit?
>>>> It's really annoying to test out some code and having to fix a bunch of
>>>> stupid uint->size_t bugs just because the author is still on a 32 bit
>>>> machine.
>>>>
>>>> Is that feasible?
>>>
>>> In general, no. What you're asking is for the compiler to compile your
>>> code twice, once
>>> for 32-bit and once for 64-bit.
>>
>> No it isn't. It's basically asking to make size_t/ptrdiff_t not
>> implicitly convertible to uint/int, or at least issue a warning if you
>> implicitly convert between them.
>>
>> At least some Microsoft C++ complier versions have this warning.
>>
>> Stewart.
>
> I generally like the idea of making size_t strongly typed, but
> that would necessitate X!size_t to become a distinct instantiation from X!uint or X!ulong. Furthermore, it would break all existing D programs that are deliberately not 64 bit aware =).

I like the idea, too. Memory sizes and collection lengths are numbers of machine word size. This is a logically distinct type. I want to support my claim with this article: http://en.wikipedia.org/wiki/Integer_(computer_science)#Words
Although past systems had 24-bit architectures, in practice today a machine word maps to either uint or ulong. So what I have in mind is a machine word "typedef": It is logically different from both uint and ulong, but template instances using it are mapped to either uint or ulong (the semantically equivalent). As a new keyword, it would also look ok with syntax highlighting editors and remove size_t, which does look so so.

	void* allocate(word size);
January 21, 2012
> Couldn't it be handled by a special switch on 64 bit compilers, and disabled normally?

Theoretically yes, but it would destroy the original intention.
Ensuring 64 bit compatibility is as easy as compiling with -m64 from time to time, but some people can't be bothered.
They won't use a new switch either.
« First   ‹ Prev
1 2 3