Thread overview | ||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Trass3r | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Trass3r | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Peter Alexander | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stewart Gordon | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stewart Gordon | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matt Soucy | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timon Gehr | 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 | ||||
---|---|---|---|---|
| ||||
Posted in reply to Matt Soucy | > 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.
|
Copyright © 1999-2021 by the D Language Foundation