View mode: basic / threaded / horizontal-split · Log in · Help
July 08, 2009
Re: dmd 1.046 and 2.031 releases
On Tue, 07 Jul 2009 18:26:36 -0700, Walter Bright wrote:


> All the messages from the dawn of time are online and available at 
> http://www.digitalmars.com/d/archives/digitalmars/D/ and are searchable 
> from the search box in the upper left.

Okaaayy ... I see that this (checking for integer overflow) has been an
issue since at least 2003. 

 http://www.digitalmars.com/d/archives/19850.html

At this rate, D v2 will be released some time after C++0X :-)

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell
July 08, 2009
Re: dmd 1.046 and 2.031 releases
On Tue, 07 Jul 2009 21:05:45 -0400, Walter Bright  
<newshound1@digitalmars.com> wrote:

> Andrei Alexandrescu wrote:
>> Robert Jacques wrote:
>>>>> long g;
>>>>> g = e + f;  => d = cast(long) e + cast(long) f;
>>>>
>>>> Works today.
>>>
>>> Wrong. I just tested this and what happens today is:
>>> g = cast(long)(e+f);
>>> And this is (I think) correct behavior according to the new rules and  
>>> not a bug. In the new rules int is special, in this suggestion, it's  
>>> not.
>>  I think this is a good idea that would improve things. I think,  
>> however, it would be troublesome to implement because expressions are  
>> typed bottom-up. The need here is to "teleport" type information from  
>> the assignment node to the addition node, which is downwards. And I'm  
>> not sure how this would generalize to other operators beyond "=".
>
> It's also troublesome because it would silently produce different  
> answers than C would.

Please, correct me if I'm wrong, but it seems C works by promoting  
byte/short/etc to int and then casting back down if need be. (Something  
tells me this wasn't always true) So (I think) the differences would be  
limited to integer expressions assigned to longs. Also, doing this 'right'  
might be important to 64-bit platforms.

Actually, after finding and skiming the C spec (from  
http://frama-c.cea.fr/download/acsl_1.4.pdf via wikipedia)

"
2.2.3 Typing
The language of logic expressions is typed (as in multi-sorted first-order  
logic). Types are either C types
or logic types defined as follows:
 ?mathematical? types: integer for unbounded, mathematical integers, real  
for real numbers,
boolean for booleans (with values written \true and \false);
 logic types introduced by the specification writer (see Section 2.6).
There are implicit coercions for numeric types:
 C integral types char, short, int and long, signed or unsigned, are all  
subtypes of type
integer;
 integer is itself a subtype of type real;
 C types float and double are subtypes of type real.

...

2.2.4 Integer arithmetic and machine integers
The following integer arithmetic operations apply to mathematical  
integers: addition, subtraction, multiplication,
unary minus. The value of a C variable of an integral type is promoted to  
a mathematical
integer. As a consequence, there is no such thing as "arithmetic overflow"  
in logic expressions.
Division and modulo are also mathematical operations, which coincide with  
the corresponding C
operations on C machine integers, thus following the ANSI C99 conventions.  
In particular, these are not
the usual mathematical Euclidean division and remainder. Generally  
speaking, division rounds the result
towards zero. The results are not specified if divisor is zero; otherwise  
if q and r are the quotient and the
remainder of n divided by d then:"
"

So by the spec   (and please correct me if I'm reading this wrong)
g = e + f => g = cast(long)(  cast(integer)e + cast(integer)f  );
where integer is unbounded in bits (and therefore has no overflow)
therefore
g = e + f;  => d = cast(long) e + cast(long) f;
is more in keeping with the spec than
g = cast(long)(e+f);
in terms of a practical implementation, since there's less possibility for  
overflow error.

(Caveat: most 32-bit compilers probably defaulted integer to int, though  
64-bit compilers are probably defaulting integer to long.)
July 08, 2009
Re: dmd 1.046 and 2.031 releases
"Walter Bright" <newshound1@digitalmars.com> wrote in message 
news:h2s0me$30f2$1@digitalmars.com...
> Something for everyone here.
>
>
> http://www.digitalmars.com/d/1.0/changelog.html
> http://ftp.digitalmars.com/dmd.1.046.zip
>
>
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.031.zip

Great release, thanks to all those that have contributed to it!

Walter, since the lib/include folders were split according to OS, the dmd2 
zip consistently has an extensionless "lib" file in the dmd2 folder.

This is because of the 'install' target in win32.mak that would previously 
copy phobos.lib and gcstub.obj to the lib folder, but now copies their 
contents to a file called "lib" instead.

I've made a patch and attached it to 
http://d.puremagic.com/issues/show_bug.cgi?id=3153

L.
July 08, 2009
Re: dmd 1.046 and 2.031 releases
On Tue, 07 Jul 2009 11:05:31 -0400, bearophile wrote:

> KennyTM~ Wrote:
>> Maybe http://msdn.microsoft.com/en-us/vcsharp/aa336815.aspx .
> 
> That compromise design looks good to be adopted by D too :-)
> 
> Bye,
> bearophile

For which we have, case 1, 2, 3: writeln("I believe");
July 08, 2009
Re: dmd 1.046 and 2.031 releases
Robert Jacques wrote:
> So by the spec   (and please correct me if I'm reading this wrong)
> g = e + f => g = cast(long)(  cast(integer)e + cast(integer)f  );
> where integer is unbounded in bits (and therefore has no overflow)
> therefore
> g = e + f;  => d = cast(long) e + cast(long) f;
> is more in keeping with the spec than
> g = cast(long)(e+f);
> in terms of a practical implementation, since there's less possibility 
> for overflow error.

The spec leaves a lot of room for implementation defined behavior. But 
still, there are common definitions for those implementation defined 
behaviors, and C programs routinely rely on them. Just like the C 
standard supports 32 bit "bytes", but essentially zero C programs will 
port to such a platform without major rewrites.

Silently changing the expected results is a significant problem. The guy 
who does the translation is hardly likely to be the guy who wrote the 
program. When he notices the program failing, I guarantee he'll write it 
off as "D sux". He doesn't have the time to debug what looks like a 
fault in D, and frankly I would agree with him.

I have a lot of experience with people porting C/C++ programs to Digital 
Mars compilers. They run into some implementation-defined issue, or rely 
on some bug in B/M/X compilers, and yet it's always DM's problem, not 
B/M/X or the code. There's no point in fighting that, it's just the way 
it is, and to deal with reality means that DM must follow the same 
implementation-defined behavior and bugs as B/M/X compilers do.

For a C integer expression, D must either refuse to compile it or 
produce the same results.

> (Caveat: most 32-bit compilers probably defaulted integer to int, though 
> 64-bit compilers are probably defaulting integer to long.)

All 32 bit C compilers defaulted int to 32 bits. 64 bit C compilers are 
setting int at 32 bits for sensible compatibility reasons.
July 08, 2009
Re: dmd 1.046 and 2.031 releases
Thanks.
July 08, 2009
Re: dmd 1.046 and 2.031 releases
On Tue, 07 Jul 2009 23:01:58 -0400, Walter Bright  
<newshound1@digitalmars.com> wrote:
> Robert Jacques wrote:
>> (Caveat: most 32-bit compilers probably defaulted integer to int,  
>> though 64-bit compilers are probably defaulting integer to long.)
>
> All 32 bit C compilers defaulted int to 32 bits. 64 bit C compilers are  
> setting int at 32 bits for sensible compatibility reasons.

But are the 64-bit compilers setting the internal "integer" type to 32 or  
64 bits? (I'm not running any 64-bit OSes at the moment to test this)
July 08, 2009
Re: dmd 1.046 and 2.031 releases
Robert Jacques wrote:
> On Tue, 07 Jul 2009 23:01:58 -0400, Walter Bright 
> <newshound1@digitalmars.com> wrote:
>> Robert Jacques wrote:
>>> (Caveat: most 32-bit compilers probably defaulted integer to int, 
>>> though 64-bit compilers are probably defaulting integer to long.)
>>
>> All 32 bit C compilers defaulted int to 32 bits. 64 bit C compilers 
>> are setting int at 32 bits for sensible compatibility reasons.
> 
> But are the 64-bit compilers setting the internal "integer" type to 32 
> or 64 bits? (I'm not running any 64-bit OSes at the moment to test this)

Not that I've seen. I'd be very surprised if any did.
July 08, 2009
Re: dmd 1.046 and 2.031 releases
Walter Bright wrote:
> Robert Jacques wrote:
>> On Tue, 07 Jul 2009 23:01:58 -0400, Walter Bright
>> <newshound1@digitalmars.com> wrote:
>>> Robert Jacques wrote:
>>>> (Caveat: most 32-bit compilers probably defaulted integer to int,
>>>> though 64-bit compilers are probably defaulting integer to long.)
>>>
>>> All 32 bit C compilers defaulted int to 32 bits. 64 bit C compilers
>>> are setting int at 32 bits for sensible compatibility reasons.
>>
>> But are the 64-bit compilers setting the internal "integer" type to 32
>> or 64 bits? (I'm not running any 64-bit OSes at the moment to test this)
> 
> Not that I've seen. I'd be very surprised if any did.

>From wikipedia: http://en.wikipedia.org/wiki/64-bit

model 	short 	int 	long 	llong 	ptrs 	Sample operating systems
LLP64 	16 	32 	32 	64 	64 	Microsoft Win64 (X64/IA64)
LP64 	16 	32 	64 	64 	64 	Most UNIX and UNIX-like systems
                                               (Solaris, Linux, etc)
ILP64 	16 	64 	64 	64 	64 	HAL
SILP64 	64 	64 	64 	64 	64 	 ?
July 08, 2009
Re: dmd 1.046 and 2.031 releases
On Wed, 08 Jul 2009 00:08:13 -0400, Brad Roberts <braddr@puremagic.com>  
wrote:

> Walter Bright wrote:
>> Robert Jacques wrote:
>>> On Tue, 07 Jul 2009 23:01:58 -0400, Walter Bright
>>> <newshound1@digitalmars.com> wrote:
>>>> Robert Jacques wrote:
>>>>> (Caveat: most 32-bit compilers probably defaulted integer to int,
>>>>> though 64-bit compilers are probably defaulting integer to long.)
>>>>
>>>> All 32 bit C compilers defaulted int to 32 bits. 64 bit C compilers
>>>> are setting int at 32 bits for sensible compatibility reasons.
>>>
>>> But are the 64-bit compilers setting the internal "integer" type to 32
>>> or 64 bits? (I'm not running any 64-bit OSes at the moment to test  
>>> this)
>>
>> Not that I've seen. I'd be very surprised if any did.
>
>> From wikipedia: http://en.wikipedia.org/wiki/64-bit
>
> model 	short 	int 	long 	llong 	ptrs 	Sample operating systems
> LLP64 	16 	32 	32 	64 	64 	Microsoft Win64 (X64/IA64)
> LP64 	16 	32 	64 	64 	64 	Most UNIX and UNIX-like systems
>                                                 (Solaris, Linux, etc)
> ILP64 	16 	64 	64 	64 	64 	HAL
> SILP64 	64 	64 	64 	64 	64 	 ?

Thanks, but what we're looking for is is what format the data is in in  
register. For example, in 32-bit C, bytes/shorts are computed as ints and  
truncated back down. I've found some references to 64-bit native integers  
in the CLI spec, but nothing definative.

The question boils down to is b == 0 or not:

int a = 2147483647;
long b = a+a+2; // or long long depending on platform
15 16 17 18 19 20 21
Top | Discussion index | About this forum | D home