View mode: basic / threaded / horizontal-split · Log in · Help
January 21, 2012
Re: 64Bit compatibility warnings
On 21/01/12 12: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.

size_t is defined in druntime as an alias to uint/ulong. The compiler is 
unaware of any special status that it may have.
January 21, 2012
Re: 64Bit compatibility warnings
"Trass3r" <un@known.com> wrote in message news:op.v8flqsr63ncmek@enigma...
>> 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.

Or they're on windows.

> They won't use a new switch either.
January 21, 2012
Re: 64Bit compatibility warnings
> Or they're on windows.

No excuse. Now there are prebuilt gdc packages :)
January 21, 2012
Re: 64Bit compatibility warnings
On 21/01/2012 11:43, Peter Alexander wrote:
<snip>
> size_t is defined in druntime as an alias to uint/ulong.

In C++ too, size_t is defined in the standard library.

> The compiler is unaware of any special status that it may have.

The whole point of what I'm saying is that it doesn't need to be.

writefln is a library function.  But DMD recognises it specially, so that it can give 
"perhaps you need to import std.stdio;" if you try using it.

In the same way, it could recognise size_t/ptrdiff_t specially, by treating them 
internally as strong types even if they aren't - so that if you try to use one as a 
uint/int, it will give a warning.  Just like the M$ C++ compiler does.

OK, so it's simpler if size_t and ptrdiff_t are changed to built-in types, but my point is 
that it's not strictly necessary.

From what I gather, some C++ compilers do more than this: they have a built-in 
understanding of the STL types, which they can use to optimise operations on them better 
than can be done in the code implementations of them.

Stewart.
January 21, 2012
Re: 64Bit compatibility warnings
On Saturday, 21 January 2012 at 12:53:27 UTC, Nick Sabalausky 
wrote:
> "Trass3r" <un@known.com> wrote in message 
> news:op.v8flqsr63ncmek@enigma...
>>> 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.
>
> Or they're on windows.

-m64 -o- should work on Windows regardless.
January 21, 2012
Re: 64Bit compatibility warnings
Stewart Gordon:

>  From what I gather, some C++ compilers do more than this: they have a built-in 
> understanding of the STL types, which they can use to optimise operations on them better 
> than can be done in the code implementations of them.

I presume future D compilers will recognize things like map/filter calls and compile them better :-)

Bye,
bearophile
January 21, 2012
Re: 64Bit compatibility warnings
On 21/01/2012 13:33, Vladimir Panteleev wrote:
> On Saturday, 21 January 2012 at 12:53:27 UTC, Nick Sabalausky wrote:
>> "Trass3r" <un@known.com> wrote in message
>> news:op.v8flqsr63ncmek@enigma...
>>>> 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.
>>
>> Or they're on windows.
>
> -m64 -o- should work on Windows regardless.


I got an ICE last time i tried that with DMD (haven't tried the latest 
version though).

I've just been making some changes to Juno to fix 64bit issues found by 
GDC, and that will do 64bit builds even on 32bit hosts, so it's pretty 
straight forward to give it a try.
January 21, 2012
Re: 64Bit compatibility warnings
On Saturday, January 21, 2012 07:53:51 Nick Sabalausky wrote:
> "Trass3r" <un@known.com> wrote in message news:op.v8flqsr63ncmek@enigma...
> 
> >> 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.
> 
> Or they're on windows.

Then you've got the added fun of whether it builds on Linux or any other Posix 
system _anyway_. To really know whether something is going to work on a system 
other than the one you're developing on, you need to buid it and run into on 
other systems (or built it _for_ other systems and then run it there in the 
case of cross-compiling).

It would be nice if size_t were handled better, but a flag for 64-bit would 
only solve _one_ of the problems related to writing code on one system and 
trying to run it on another, and that's assuming that it actually solved the 
problem for 64-bit, which it wouldn't, since you could still have version 
differences beyond size_t. It would just help with the very common (and 
understandably annoying) issue of using size_t correctly on 32-bit box such 
that it would work on a 64-bit box.

So, it may very well be worth having something in the compiler flag obvious 
mis-use of size_t, but it doesn't really solve the problem, just mitigate it.

- Jonathan M Davis
January 24, 2012
Re: 64Bit compatibility warnings
On 20/01/12 01:25, 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?


IMHO the ideal solution would be:
- treat size_t as a magical type (not a simple alias).
- allow size_t -> uint if you are in a machine-specific version 
statement that implies 32 bits (eg, version(D_InlineAsm_X86), 
version(Win32), version(X86)).
- allow size_t -> ulong if you are in a version statement that implies 
64 bits.
- Otherwise, disallow implicit casts.

Incidentally this was a motivation for the 'one-definition rule' that I 
proposed for version statements: it means the compiler can easily 
identify which versions imply machine-specific.
January 24, 2012
Re: 64Bit compatibility warnings
On 24/01/2012 10:37, Don Clugston wrote:
<snip>
> IMHO the ideal solution would be:
> - treat size_t as a magical type (not a simple alias).
> - allow size_t -> uint if you are in a machine-specific version statement that implies 32
> bits (eg, version(D_InlineAsm_X86), version(Win32), version(X86)).
> - allow size_t -> ulong if you are in a version statement that implies 64 bits.
> - Otherwise, disallow implicit casts.
<snip>

And have what rules for implicit conversions _to_ size_t?

Stewart.
1 2 3
Top | Discussion index | About this forum | D home