On 11/21/2014 12:31 AM, Daniel Murphy wrote:
> 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

Presumably read() will throw if the size is larger than it can handle. If it doesn't, this code is not buggy, but read() is.

"Walter Bright"  wrote in message news:m4mu0q$sc5$1@digitalmars.com...

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

It would be even less costly if they weren't possible. 

"Walter Bright"  wrote in message news:m4mua1$shh$1@digitalmars.com...

> Presumably read() will throw if the size is larger than it can handle. If it doesn't, this code is not buggy, but read() is.

You're right, but that's really not the point. 

Daniel Murphy:

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

Better (it's a workaround for a D design flaw that we're unwilling to fix):

foreach_reverse(immutable i, 0...a.length)

Bye,
bearophile

On Friday, 21 November 2014 at 08:54:40 UTC, Daniel Murphy wrote:
> "Walter Bright"  wrote in message news:m4mu0q$sc5$1@digitalmars.com...
>
>> > 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.
>
> It would be even less costly if they weren't possible.

C# has the checked and unchecked operators (http://msdn.microsoft.com/en-us/library/khy08726.aspx), which allow the programmer to specify if overflows should wrap of fail within an arithmetic expression. That could be a useful addition to D.

However, a language that doesn't have unsigned integers and modular arithmetic is IMHO not a system language, because that is how most hardware works internally.

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

This will be ok:

writeln("Difference: ", (l1 >l2)? (l1 - l2):(l2 - l1));

If 'length''s type is not 'size_t',but is 'int' or 'long', it will be ok like this:

import std.math;
writeln("Difference: ", abs(l1 >l2));

Mathematical difference between unsigned value,size comparison should be done before in the right side of the equal sign character.

If this work is done in druntime,D will be a real system language.

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.

Wrong. Unsigned integers can hold bigger values, so it takes more to makes them overflow, hence the bug is harder to detect.

> http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html
> Specifically, it fails if the sum of low and high is greater than the maximum positive int value

So it fails sooner for signed integers than for unsigned integers.

On Thursday, 20 November 2014 at 21:27:11 UTC, Walter Bright wrote:
> If that is changed to a signed type, then you'll have a same-only-different set of subtle bugs

If people use signed length with unsigned integers, the length with implicitly convert to unsigned and behave like now, no difference.

> plus you'll break the intuition about these things from everyone who has used C/C++ a lot.

C/C++ programmers disagree: http://critical.eschertech.com/2010/04/07/danger-unsigned-types-used-here/
Why do you think they can't handle signed integers?

Mathematical difference between unsigned value,size comparison
should be done before in the right side of the equal sign
character.

such as:  l3 = (l1 >l2)? (l1 - l2):(l2 - l1);

If this work is done in druntime,small bug will be rarely.D will be a real system language.

Frank

On Thursday, 20 November 2014 at 16:03:41 UTC, H. S. Teoh via Digitalmars-d wrote:
> 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.

The type is chosen at design time so that it's unlikely to overflow for the particular scenario. Why would you want the count of objects to reset at some point when counting objects? Wrapping of unsigned integers has valid usage for e.g. hash functions, but there they are used as bit arrays, not proper numbers, and arithmetic operators are used for bit shuffling, not for computing some numbers.