View mode: basic / threaded / horizontal-split · Log in · Help
January 20, 2012
64Bit compatibility warnings
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
Re: 64Bit compatibility warnings
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
Re: 64Bit compatibility warnings
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
Re: 64Bit compatibility warnings
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
Re: 64Bit compatibility warnings
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
Re: 64Bit compatibility warnings
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
Re: 64Bit compatibility warnings
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
Re: 64Bit compatibility warnings
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
Re: 64Bit compatibility warnings
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
Re: 64Bit compatibility warnings
> 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
Top | Discussion index | About this forum | D home