On 11/20/2014 7:11 PM, Walter Bright wrote:
> On 11/20/2014 3:25 PM, bearophile wrote:
>> Walter Bright:
>>
>>> If that is changed to a signed type, then you'll have a same-only-different
>>> set of subtle bugs,
>>
>> This is possible. Can you show some of the bugs, we can discuss them, and see if
>> they are actually worse than the current situation.
>
> All you're doing is trading 0 crossing for 0x7FFFFFFF crossing issues, and
> pretending the problems have gone away.

BTW, granted the 0x7FFFFFFF problems exhibit the bugs less often, but paradoxically this can make the bug worse, because then it only gets found much, much later in supposedly tested & robust code.

0 crossing bugs tend to show up much sooner, and often immediately.

On Friday, 21 November 2014 at 04:53:38 UTC, Walter Bright wrote:
> BTW, granted the 0x7FFFFFFF problems exhibit the bugs less often, but paradoxically this can make the bug worse, because then it only gets found much, much later in supposedly tested & robust code.
>
> 0 crossing bugs tend to show up much sooner, and often immediately.

Yes, I have to say the current design has some issue, but alternative seems worse.

"H. S. Teoh via Digitalmars-d"  wrote in message news:mailman.2156.1416499421.9932.digitalmars-d@puremagic.com...

> By that logic, using an int to represent an integer is also using the
> incorrect type, because a signed type is *also* subject to module 2^^n
> arithmetic -- just a different form of it where the most negative value
> wraps around to the most positive values.  Fixed-width integers in
> computing are NOT the same thing as unrestricted integers in
> mathematics. No matter how you try to rationalize it, as long as you use
> hardware fix-width "integers", you're dealing with modulo arithmetic in
> one form or another. Pretending you're not, is the real source of said
> subtle bugs.

While what you've said is true, the typical range of values stored in an integral type is much more likely to cause unsigned wrapping than signed overflow.  So to get the desired 'integer-like' behaviour from D's integral types, you need to care about magnitude for signed types, or both magnitude and ordering for unsigned types.

eg 'a < b' becoming 'a - b < 0' is valid for integers, and small ints, but not valid for small uints unless a > b.  You will always have to care about the imperfect representation of mathematical integers, but with unsigned types you have an extra rule that is much more likely to affect typical code. 

"FrankLike"  wrote in message news:musbvhmuuhhvetovxqwb@forum.dlang.org...

> If you compile the dfl Library to 64 bit,you will find error:
>
> core.sys.windows.windows.WaitForMultipleObjects(uint
> nCount,void** lpHandles,....) is not callable using argument
> types(ulong,void**,...)
>
> the 'WaitForMultipleObjects' Function is in
> dmd2/src/druntime/src/core/sys/windows/windows.d
>
> the argument of first is dfl's value ,it comes from a 'length'
> ,it's type is size_t,now it is 'ulong' on 64 bit.
>
> So druntime must keep the same as  phobos for size_t.
> Or  keep the same to int with WindowsAPI to  modify the size_t to int ?

I suggest using WaitForMultipleObjects(to!uint(xxx.length), ...) as it will both convert and check for overflow IIRC.  I'm just happy D gives you an error here instead of silently truncating the value. 

"Walter Bright"  wrote in message news:m4mggi$e1h$1@digitalmars.com...

> BTW, granted the 0x7FFFFFFF problems exhibit the bugs less often, but paradoxically this can make the bug worse, because then it only gets found
> much, much later in supposedly tested & robust code.
>
> 0 crossing bugs tend to show up much sooner, and often immediately.

I don't think I have ever written a D program where an array had more than 2^^31 elements.  And I'm sure I've never had it where 2^31-1 wasn't enough and yet 2^^32-1 was.

Zero, on the other hand, is usually quite near the typical array lengths and differences in lengths. 

Walter Bright:

> All you're doing is trading 0 crossing for 0x7FFFFFFF crossing issues, and pretending the problems have gone away.

I'm not pretending anything. I am asking in practical programming what of the two solutions leads to leas problems/bugs. So far I've seen the unsigned solution and I've seen it's highly bug-prone.


> BTW, granted the 0x7FFFFFFF problems exhibit the bugs less often, but paradoxically this can make the bug worse, because then it only gets found much, much later in supposedly tested & robust code.

Is this true? Do you have some examples of buggy code?

Bye,
bearophile

"Andrei Alexandrescu"  wrote in message news:m4l711$1t39$1@digitalmars.com...

> The most difficult pattern that comes to mind is the "long arrow" operator seen in backward iteration:
>
> void fun(int[] a)
> {
>      for (auto i = a.length; i --> 0; )
>      {
>          // use i
>      }
> }

Over the years most of my unsigned-related bugs have been from screwing up various loop conditions.  Thankfully D solves this perfectly with:

void fun(int[] a)
{
   foreach_reverse(i, 0...a.length)
   {
   }
}

So I never have to write those again. 

"bearophile"  wrote in message news:lkcltlokangpzzdzzfjg@forum.dlang.org...

> From my experience in coding in D they are far more unlikely than sign-related bugs of array lengths.

Here's a simple program to calculate the relative size of two files, that will not work correctly with unsigned lengths.

module sizediff

import std.file;
import std.stdio;

void main(string[] args)
{
   assert(args.length == 3, "Usage: sizediff file1 file2");
   auto l1 = args[1].read().length;
   auto l2 = args[2].read().length;
   writeln("Difference: ", l1 - l2);
}

The two ways this can fail (that I want to highlight) are:
1. If either file is too large to fit in a size_t the result will (probably) be wrong
2. If file2 is bigger than file1 the result will be wrong

If length was signed, problem 2 would not exist, and problem 1 would be more likely to occur.  I think it's clear that signed lengths would work for more possible realistic inputs.

While this is just an example, a similar pattern occurs in real code whenever array/range lengths are subtracted. 

On 11/21/2014 12:10 AM, Daniel Murphy wrote:
> "Walter Bright"  wrote in message news:m4mggi$e1h$1@digitalmars.com...
>
>> BTW, granted the 0x7FFFFFFF problems exhibit the bugs less often, but
>> paradoxically this can make the bug worse, because then it only gets found
>> much, much later in supposedly tested & robust code.
>>
>> 0 crossing bugs tend to show up much sooner, and often immediately.
>
> I don't think I have ever written a D program where an array had more than 2^^31
> elements.  And I'm sure I've never had it where 2^31-1 wasn't enough and yet
> 2^^32-1 was.

There turned out to be such a bug in one of the examples in "Programming Pearls" that remained undetected for many years:

http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html


> Zero, on the other hand, is usually quite near the typical array lengths and
> differences in lengths.

That's true, that's why they are detected sooner, when it is less costly to fix them.

On 11/21/2014 12:10 AM, bearophile wrote:
> Walter Bright:
>
>> All you're doing is trading 0 crossing for 0x7FFFFFFF crossing issues, and
>> pretending the problems have gone away.
>
> I'm not pretending anything. I am asking in practical programming what of the
> two solutions leads to leas problems/bugs. So far I've seen the unsigned
> solution and I've seen it's highly bug-prone.

I'm suggesting that having a bug and detecting the bug are two different things. The 0-crossing bug is easier to detect, but that doesn't mean that shifting the problem to 0x7FFFFFFF crossing bugs is making the bug count less.


>> BTW, granted the 0x7FFFFFFF problems exhibit the bugs less often, but
>> paradoxically this can make the bug worse, because then it only gets found
>> much, much later in supposedly tested & robust code.
>
> Is this true? Do you have some examples of buggy code?

http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html