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

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.)

"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. 

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");

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.

Thanks.

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)

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.

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 	 ?

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